compras/docs/orientacoes-continuidade.md

Continuidade do desenvolvimento do ProcuraFlow

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.