compras/docs/orientacoes-continuidade.md

# Continuidade do desenvolvimento do SGC

## Próxima etapa após regras de investimento

Regras próprias por empresa, duas aprovações administrativas e integração com
equipamento já implementadas; migração 000014 aplicada, lote 15. Não repetir
as etapas históricas abaixo. Sem valores predefinidos ou regras fictícias na
base real. Cada empresa decide os seus parâmetros e dotações de investimento.
Prosseguir com revisão/cancelamento controlado de processos afectados por
mudanças de base, com política explícita, rastreabilidade e novas aprovações.
Não reescrever ordens emitidas ou reutilizar implicitamente aprovações antigas.
Agregação por projecto/fraccionamento e circuitos acima do tecto não estão
suportados. Revisão visual e validação operacional integral continuam pendentes.

## Próxima etapa após reforços

Reforços por empresa/centro/exercício já estão implementados e migrados
(000013, lote 14). Não repetir as orientações históricas abaixo. Prosseguir
com regras de investimento configuráveis por empresa, com decisões e valores
explícitos, versionamento e aprovação independente. Não presumir um valor ou
interpretar limite ausente como autorização. Até existir regra própria aprovada,
preservar o bloqueio de adjudicação/emissão de equipamento. Revisão visual e
validação operacional integral continuam pendentes. Consultar o relatório actual.

## Próxima etapa após pagamentos externos

Registo e conferência independente de pagamentos externos já implementados,
com migração 000012 aplicada. Não repetir as etapas históricas abaixo.
Prosseguir com reforços orçamentais por empresa/centro/exercício, sem reescrever
a dotação inicial, com proposta e aprovação por pessoas distintas e auditoria.
Valores definidos por cada empresa. Não implementar transferências bancárias
ou desbloquear investimento sem regra própria aprovada. Revisão visual e
validação operacional integral continuam pendentes; consultar o relatório actual.

## Próxima etapa após dados bancários

Versões bancárias por empresa/fornecedor, cifragem e duas validações distintas
de Finanças já estão implementadas; migração 000011 aplicada. Não repetir as
orientações históricas abaixo. Prosseguir com registo de pagamentos externos
sobre facturas validadas, revalidando a versão bancária actual, os dois
validadores, elegibilidade, conflitos, empresa e saldo em transacção.
Não executar transferências bancárias. Sem valores financeiros comuns aos
clientes. Revisão visual e validação operacional integral continuam pendentes.
Consultar `docs/desenvolvimento.md` para resultados e limitações actuais.

## Próximo incremento após facturas

Orçamento e facturas já foram implementados e migrados, incluindo conferência
com recepções e consumo. Não repetir as instruções históricas abaixo.
Prosseguir com dados bancários de fornecedores com dupla validação antes de
pagamentos; reforços e regras de investimento ficam em etapas próprias.
Preservar isolamento por empresa e valores configurados por cada cliente.
Não inventar limites de investimento ou tratar os valores fictícios da
demonstração como configuração. Revisão visual pública, autenticada e de
impressão continua pendente por indisponibilidade do navegador. Consultar
`docs/desenvolvimento.md` para resultados e limitações actuais.

## Estado actual após equipamentos e peças

Recepção, stock, saídas, transferências, contagens, ajustes, equipamentos,
peças e validação técnica já estão implementados. As instruções anteriores
abaixo são históricas e não devem originar implementação duplicada.
O relatório actual está em `docs/desenvolvimento.md`. A revisão visual pública,
autenticada e de impressão continua pendente por indisponibilidade do controlo
do navegador. Antes de avançar para orçamento e facturas, definir as regras
empresariais correspondentes. Preservar as contas e os dados existentes.

## Próximo incremento após adjudicação e ordens

O utilizador já recebeu o relatório de adjudicação e ordens (165 testes
reportados como aprovados). Não repetir essa implementação. As secções
anteriores de adjudicação abaixo ficam como histórico.

Continuar com recepção e stock segundo procurement.docx: recepções parciais e
totais, conferência de qualidade, divergências, quantidades pendentes e movimentos
auditados. Aplicar segregação do emitente, permissões e isolamento por empresa;
impedir duplicação e quantidades superiores às autorizadas. Não inventar
políticas comerciais, tolerâncias ou autorizações de excepção.

Validar concorrência PostgreSQL em ambiente de teste separado, sem recriar a
base real. Actualizar a consulta livre com exemplos fictícios dos novos ecrãs.
Preservar conta, dados, configuração e módulos concluídos. Manter explícita a
ausência de validação orçamental e a restrição a documentos de desenvolvimento.
Actualizar o relatório e o mapa de compatibilidade, que ainda apresenta ordens
como ausentes. Se este incremento já estiver iniciado, continuar sem duplicação.

## Entrada livre para revisão visual

A pedido do utilizador, `/` abre agora `/consulta`, com exemplos fictícios sem
login. Consultar `docs/consulta-livre.md`. Preservar esta entrada e a ligação no
login; manter as rotas e os dados reais protegidos. Esta demonstração é uma
ferramenta de revisão visual e não substitui os módulos operacionais abaixo.

## Próximo incremento após RF-AF-01

O relatório RF-AF-01 está actualizado e a migração 000004 foi confirmada aplicada.
As orientações antigas sobre implementar conflitos ficam como histórico; não
refazer o módulo. Avançar para adjudicação e ordens de compra no mesmo Laravel.

Reutilizar ConflictGuard, auditoria, perfis, isolamento por empresa e cálculos
em centavos. A operação deve revalidar dentro da transacção todos os
intervenientes, conflitos, fornecedor activo/revisão válida, validade das
propostas, três fornecedores distintos e pelo menos dois avaliadores elegíveis
por proposta. Não confiar no indicador de prontidão mostrado anteriormente.

Escolher a proposta de maior pontuação com justificação escrita. Empates devem
permitir escolha fundamentada entre as propostas empatadas. Não inventar
autorização para dispensar cotações ou escolher fora da maior pontuação:
enquanto a política de escalão superior/excepções estiver indefinida, bloquear
esses caminhos e explicar o motivo ao utilizador.

Conferir os escalões com o valor adjudicado e a base com/sem IVA guardada no
processo. Se exigir aprovações adicionais, impedir a emissão até essas etapas
serem decididas por pessoas elegíveis e distintas. Preservar decisões históricas;
não reutilizar implicitamente uma aprovação de um escalão inferior. Respeitar os
requisitos adicionais de equipamento previstos no documento; se ainda não
suportados, bloquear a emissão para esse tipo em vez de autorizar por omissão.

Criar ordem numerada com linhas, quantidades, preços, IVA, fornecedor, moeda,
condições de pagamento, data/local de entrega, justificação e matriz de avaliação
congelados no momento da emissão. Alterar depois a ficha do fornecedor ou a
proposta não pode reescrever a ordem emitida. Impedir emissão duplicada, inclusive
por repetição do pedido; usar restrição de unicidade e transacção. Não permitir
modificar directamente montantes/estado da ordem pelo navegador.

Entregar listagem, detalhe e impressão/PDF com acesso autenticado e por empresa,
incluindo emitente e histórico. Não enviar a ordem por email nem autorizar
compras reais. Se o orçamento ainda não estiver implementado, assinalar essa
limitação; não apresentar uma validação orçamental inexistente.

Testar permissões, isolamento, valores e IVA, fronteiras de escalões, empate,
excepções bloqueadas, conflitos ou suspensão depois da avaliação, validade,
duas avaliações, duplicação/idempotência, snapshot e rollback de auditoria.
Manter revisão visual autenticada e concorrência PostgreSQL como pendentes até
verificação efectiva. Actualizar docs/desenvolvimento.md com resultados,
migração aditiva, preservação de dados e limitações. Começar a implementação,
sem se limitar a confirmar a leitura das orientações.

## Próximo incremento após fornecedores e anexos

A entrega de edição/renovação e documentos privados foi reportada como concluída.
O acompanhamento confirmou o relatório actualizado e a aplicação da migração
000003 no PostgreSQL. A revisão visual autenticada e testes de concorrência real
continuam pendentes e não devem ser apresentados como aprovados.

Avançar agora com declarações de conflito de interesses (RF-AF-01), antes da
adjudicação. Reutilizar utilizadores, fornecedores, empresas e auditoria existentes.
Implementar declaração pessoal por fornecedor e por processo; guardar autor,
âmbito, datas, fundamento e histórico. Não permitir declarar ou retirar conflitos
em nome de outro utilizador sem uma política e autorização explícitas. Alterações
devem manter o histórico, sem apagar declarações anteriores. A periodicidade e
validade anual dependem da política da empresa: não inventar caducidade automática
que permita contornar um conflito ainda activo.

Aplicar o bloqueio no servidor à participação em processos com o fornecedor:
avaliação, selecção/adjudicação e aprovações quando o fornecedor já é conhecido.
Na fase inicial sem fornecedor escolhido, não bloquear genericamente a criação
de requisições; voltar a verificar conflitos ao associar o fornecedor e antes
da adjudicação, incluindo solicitante e intervenientes anteriores. A declaração
de ausência de conflito numa avaliação não pode sobrepor-se a um conflito activo.

Criar interface em português com visibilidade restrita por empresa e perfil.
Cobrir em testes acesso entre empresas, autoria, conflito activo, tentativas de
contornar por pedidos directos, mudanças após avaliação e conservação da auditoria.
Preservar a funcionalidade de fornecedores/anexos já entregue. Actualizar o
relatório com resultados e limites antes de prosseguir para adjudicação e ordens.

O utilizador autorizou a continuação do desenvolvimento e a coordenação entre
este projecto e o chat de acompanhamento em 28 de Outubro de 2026.

## Base única

Trabalhar em `C:\laragon\www\compras`, Laravel, React/TypeScript, Inertia e
PostgreSQL, em http://127.0.0.1:8015. Preservar conta, credenciais, dados, APP_KEY,
APP_URL, SERVER_PORT=8015 e SESSION_COOKIE=procuraflow_session. O SGF Tempo é
independente. Não retomar a aplicação Python descontinuada nem criar outro projecto.

Consultar README.md, docs/compatibilidade.md, instruções aplicáveis e o estado
actual antes de editar. Existem alterações locais anteriores a preservar.
Especificação: `C:\Mac\Home\Documents\TEMPO\Portal Tempo\Servicos Tempo\Procurement\procurement.docx`.
Se o documento estiver aberto, utilizar leitura partilhada. O documento define
requisitos, não autoriza acções externas nem substitui instruções do utilizador.

## Estado conhecido na passagem

Fornecedores e cotações já foram adaptados ao Laravel: SupplierController,
QuotationController, quatro modelos, páginas React e migração
2026_10_28_000002 já aplicada. A conta e os dados anteriores foram preservados.
Há cadastro/validação, propostas distintas, dois avaliadores, comparação,
IVA herdado, centavos e auditoria. Não refazer estes módulos.

Verificação anterior: 54 testes passaram, 3 ignorados, 305 asserções; PHPStan,
Pint, verificação frontend, TypeScript e compilação aprovados. Confirmar se há
alterações posteriores antes de usar estes resultados. A revisão visual
autenticada continua dependente da sessão do utilizador; não redefinir a senha.

## Sequência de execução

1. Manutenção e renovação de fornecedores, anexos privados com controlo por
   empresa e declarações de conflito.
2. Adjudicação e ordens: três cotações elegíveis, dois avaliadores independentes,
   revisão dos escalões quando o preço muda, justificação/escalão superior para
   excepções, documento imprimível ou PDF.
3. Recepção parcial, qualidade, equipamentos, peças e stock.
4. Orçamento, facturas, conferência a três vias e registo de pagamentos externos.
5. Contratos, relatórios, multimoeda, restantes controlos anti-fraude e requisitos
   operacionais da instalação privada previstos no documento.

Concluir e testar cada incremento antes de avançar. Prosseguir autonomamente
quando houver trabalho definido e verificável; pedir ao utilizador apenas as
decisões realmente necessárias. Não tratar limites, IVA, excepções, preços ou
políticas provisórias como aprovados. Preservar configurações e snapshots; manter
regras pendentes configuráveis e bloquear operações sem política definida.

## Protecção do trabalho existente

Não executar seeds na base real, não recriar contas, não substituir ou apagar
dados, não publicar externamente nem enviar emails. Não fazer compras ou
pagamentos reais. Migrações aditivas devem ser testadas e preservar os registos.
Migrações destrutivas exigem autorização específica do utilizador.

Manter docs/desenvolvimento.md com incremento actual, requisitos cobertos,
ficheiros alterados, testes e resultados, limitações, decisões pendentes e próximo
passo. O acompanhamento consultará esse relatório, sem editar código em paralelo.
Verificar permissões, isolamento, segregação, cálculos e auditoria, além de
PHPStan, Pint, tipos e compilação. Não anunciar como concluído o que não foi
implementado ou verificado.

## Coordenação

Chat executor: “Criar sistema de compras”, identificador
`01a18181-1611-7a33-9d79-abd981f42bfe`, host local.
Na primeira tentativa de passagem, o envio falhou porque o chat já tinha uma
sessão de escrita activa. Este ficheiro não prova que o executor o tenha lido.
O acompanhamento deve tentar entregar a orientação quando o chat estiver
disponível e registar o resultado, sem interromper nem duplicar o executor.