@@ -0,0 +1,76 @@
|
||||
# Consolidação do ProcuraFlow
|
||||
|
||||
Estado verificado em 28 de Outubro de 2026.
|
||||
|
||||
## Projecto activo
|
||||
|
||||
O projecto activo é `C:\laragon\www\compras`, em Laravel, React, TypeScript,
|
||||
Inertia e PostgreSQL, em http://127.0.0.1:8015. A conta já foi criada.
|
||||
Preservar `APP_URL=http://127.0.0.1:8015`, `SERVER_PORT=8015`,
|
||||
`SESSION_COOKIE=procuraflow_session` e `SESSION_DRIVER=database`.
|
||||
O SGF Tempo é independente.
|
||||
|
||||
A implementação Python/React na pasta de outputs da conversa fica descontinuada
|
||||
como aplicação executável e preservada apenas como referência. Não importar
|
||||
contas sintéticas, bases SQLite, sessões ou palavras-passe. Não executar os seus
|
||||
servidores ou contentores. O iniciador antigo passa a indicar o endereço do projecto Laravel, sem iniciar outro servidor.
|
||||
|
||||
## Compatibilidade funcional
|
||||
|
||||
| Área | Base a preservar | Adaptação da referência experimental |
|
||||
| ------------------------------- | -------------------------------------------------------------------- | --------------------------------------------------------------------------- |
|
||||
| Acesso | Fortify, conta existente, sessões e equipa | Não transportar login Python nem contas fictícias |
|
||||
| Organização | Empresa, departamentos, centros de custo e isolamento | Aplicar o mesmo isolamento nos novos módulos |
|
||||
| Requisições | Rascunhos editáveis, validações, relações e numeração | Acrescentar funções sem substituir as existentes |
|
||||
| Aprovações | RequisitionWorkflow, perfis, etapas e snapshots | Adaptar cenários e testes adicionais |
|
||||
| Valores | Brick Math e centavos | Não importar o armazenamento genérico JSON |
|
||||
| Fornecedores e cotações | Cadastro, validação, propostas e comparação implementados no Laravel | Adaptados com tabelas próprias, isolamento, centavos e auditoria existentes |
|
||||
| Ordens, recepções e facturas | Ainda ausentes nesta base | Adaptar estados, recepções parciais e conferência |
|
||||
| Stock, equipamentos e orçamento | Ainda ausentes nesta base | Adaptar movimentos, mínimos, inventários e compromissos |
|
||||
| Relatórios e auditoria | Indicadores e histórico existentes | Adaptar exportação e controlos adicionais |
|
||||
|
||||
A consolidação inicial definiu a base única de continuidade. Posteriormente,
|
||||
fornecedores e cotações foram adaptados ao Laravel; os restantes módulos
|
||||
experimentais continuam por implementar nesta base.
|
||||
|
||||
## Diferenças a resolver em cada adaptação
|
||||
|
||||
- Laravel aplica provisoriamente escalões com IVA; o protótipo Python usava sem
|
||||
IVA. Preservar a configuração existente e snapshots, até decisão de Finanças.
|
||||
- Perfis e estados têm identificadores diferentes: usar os enums e políticas
|
||||
Laravel, sem criar perfis concorrentes.
|
||||
- Preservar as tabelas relacionais e o isolamento por empresa. Não importar a
|
||||
tabela JSON genérica do protótipo.
|
||||
- Manter a edição de rascunhos e a gestão da equipa já existentes no Laravel.
|
||||
- Não apresentar funcionalidades ainda ausentes como implementadas nem considerar
|
||||
o protótipo uma validação para compras reais.
|
||||
|
||||
## Verificação
|
||||
|
||||
- Página de entrada em 8015: HTTP 200 e texto “Entrar no ProcuraFlow”.
|
||||
- Testes Laravel: 47 passaram, 3 ignorados, 219 asserções.
|
||||
- Testes em SQLite em memória, conforme phpunit.xml; não na base real.
|
||||
- Nenhuma conta, credencial ou dado real foi alterado nesta consolidação.
|
||||
|
||||
## Adaptação de fornecedores e cotações
|
||||
|
||||
A migração aditiva `2026_10_28_000002_create_suppliers_and_quotations` criou
|
||||
suppliers, quotations, quotation_items e proposal_evaluations no PostgreSQL.
|
||||
A comparação dos registos antes e depois confirmou que utilizadores, empresas,
|
||||
departamentos, centros de custo, requisições, linhas e aprovações permaneceram
|
||||
inalterados. Não foram criadas contas ou dados sintéticos na base real.
|
||||
|
||||
Validações: 54 testes passaram, 3 ignorados, 305 asserções; análise estática PHP,
|
||||
tipos TypeScript, formatação e compilação da interface aprovadas.
|
||||
|
||||
Âmbito: cadastro e validação de fornecedores, propostas por requisição aprovada,
|
||||
preços em MZN, IVA herdado, avaliação independente e indicação de completude
|
||||
da matriz. Os módulos usam a conta/sessão Laravel existente. O navegador abriu
|
||||
a entrada na porta 8015; a inspecção visual das páginas autenticadas fica
|
||||
dependente do início de sessão do utilizador. Não foi pedida nem alterada a senha.
|
||||
|
||||
Edição/renovação de fornecedores e anexos privados foram acrescentados no
|
||||
incremento descrito em [desenvolvimento.md](desenvolvimento.md). Continuam
|
||||
pendentes dados bancários, registo anual de conflitos, adjudicação, ordens,
|
||||
recepção e restantes módulos. Os resultados anteriores acima referem-se à
|
||||
adaptação inicial; consultar o relatório de desenvolvimento para a validação actual.
|
||||
@@ -0,0 +1,79 @@
|
||||
# Desenvolvimento do ProcuraFlow
|
||||
|
||||
## Incremento actual RF-AF-01 de 28 de Outubro de 2026
|
||||
|
||||
### Implementado
|
||||
|
||||
Declarações pessoais de conflito de interesses na base Laravel e React existente, sem avançar para adjudicação ou ordens. Fornecedores, anexos privados, contas e configuração anteriores foram preservados. O SGF Tempo e o Investmoz não foram alterados.
|
||||
|
||||
- Interface em português em **Conflitos de interesses**, disponível para todos os perfis com empresa configurada. Cada utilizador declara exclusivamente em nome próprio. O servidor fixa autor, empresa e data/hora do registo.
|
||||
- Âmbitos: fornecedor em todos os processos; processo independentemente do fornecedor; fornecedor num processo específico. São guardados fundamento, data de conhecimento da situação e data/hora de cada declaração ou correcção.
|
||||
- Administração e Finanças consultam as declarações da sua empresa para controlo. Procurement, chefes, solicitantes e armazém consultam apenas as próprias. Nenhum perfil altera declarações alheias. As opções de fornecedores mostram só identificador e nome; as opções de processos respeitam a visibilidade do perfil e departamento.
|
||||
- As correcções pessoais acrescentam um registo ligado ao anterior e à declaração inicial. Só corrigem fundamento e data de conhecimento; autor, empresa, âmbito e situação declarada não são alteráveis. Correcções de uma versão já corrigida são recusadas. O histórico completo é consultável e gera auditoria com antes/depois.
|
||||
- Uma declaração de ausência não anula uma declaração de conflito, mesmo posterior ou noutro âmbito sobreposto. Não há caducidade, prazo anual ou autorização para retirada implementados. A data de conhecimento é descritiva e não adia o impedimento. Periodicidade, validade e levantamento dependem de decisão da empresa, sem valores presumidos.
|
||||
|
||||
### Impedimentos no servidor
|
||||
|
||||
- A requisição sem fornecedor continua a poder ser criada, editada, submetida e aprovada quando há apenas conflito com um fornecedor ainda não associado. Um conflito pessoal específico do processo, já conhecido, impede a participação nesse processo.
|
||||
- Ao associar um fornecedor através de uma cotação, o servidor verifica o operador actual, solicitante, aprovadores anteriores, autores de propostas, avaliadores anteriores e autores de acções de participação no histórico de auditoria. As verificações usam os utilizadores históricos, independentemente do perfil actual. O registo da própria declaração não é tratado como participação em compras.
|
||||
- Reedição/submissão de requisições, decisões de aprovação, registo de cotações e avaliações verificam novamente os conflitos dos intervenientes e dos fornecedores já associados. O campo de ausência de conflito de uma operação não permite contornar os impedimentos.
|
||||
- Conflitos registados depois de uma avaliação conservam as cotações, avaliações, aprovações e auditoria anteriores. A elegibilidade e a pontuação são recalculadas na comparação; propostas afectadas deixam de contar como elegíveis, e novas operações afectadas ficam impedidas. Não há alteração retroactiva dos estados ou eliminação de decisões históricas.
|
||||
- Escritas de declarações, correcções e operações de participação começam por bloquear a empresa na transacção, antes dos bloqueios do processo/fornecedor. Esta protecção abrangente serializa estas escritas por empresa; o efeito real na concorrência e desempenho ainda não foi testado. Leituras da interface não constituem autorização para uma futura adjudicação: essa operação terá de verificar novamente os impedimentos dentro da sua transacção.
|
||||
- Declarações e correcções falham integralmente se falhar a auditoria. O modelo impede edição destrutiva e eliminação; a protecção contra SQL directo ou administração da base de dados continua dependente de permissões operacionais adequadas.
|
||||
|
||||
### Verificações realizadas
|
||||
|
||||
- Laravel/Pest: **116 passaram, 3 ignorados, 808 asserções**. Inclui os testes anteriores de fornecedores e anexos e novos cenários de autoria, seis perfis, visibilidade, isolamento, correcções imutáveis, versões antigas, âmbitos, ausência sem poder de anulação, datas sem caducidade, fornecedor desconhecido, intervenientes anteriores, alterações após avaliação, bloqueios por pedidos directos, auditoria e rollback.
|
||||
- PHPStan aprovado, sem erros; Pint aprovado; verificação frontend sem avisos ou erros; TypeScript aprovado; compilação aprovada; `git diff --check` sem erros. Os testes usam SQLite em memória, não a base de negócio.
|
||||
- Migração aditiva `2026_10_28_000004_create_conflict_declarations` aplicada no PostgreSQL local depois dos testes. Contagens antes/depois preservadas: 1 utilizador, 1 empresa e 0 requisições, fornecedores, cotações, avaliações e documentos. A nova tabela está vazia; não foram criadas declarações sintéticas na base real.
|
||||
- O SHA-256 do `.env` permaneceu igual antes e depois. Não houve seeds, recriação de contas, alteração de credenciais, reinicialização de dados ou mudanças de configuração.
|
||||
- As quatro rotas de conflitos estão registadas. O acesso HTTP sem sessão a `/conflitos` redireccionou para a entrada ProcuraFlow na porta 8015, que respondeu HTTP 200. Isto não constitui revisão visual autenticada.
|
||||
|
||||
### Pendências e próximo passo
|
||||
|
||||
**Continuam pendentes a revisão visual autenticada e os testes de concorrência real em PostgreSQL.** Não foram realizados nem apresentados como aprovados. Também não foram testados carga ou desempenho dos bloqueios por empresa.
|
||||
|
||||
A política de periodicidade/validade das declarações e o procedimento autorizado para levantar ou tratar conflitos permanecem por decidir. Não há retirada de conflitos nem declarações em nome de terceiros. A entrega cobre os âmbitos e impedimentos nas operações actualmente existentes; não representa certificação integral do sistema.
|
||||
|
||||
Próximo incremento: adjudicação e ordens de compra, reutilizando `ConflictGuard` para verificar novamente todos os intervenientes e o fornecedor antes de seleccionar ou emitir, além das três cotações, avaliações independentes e escalões aplicáveis. Dados bancários com dupla validação continuam pendentes. Não avançar com políticas ou excepções comerciais ainda não definidas.
|
||||
|
||||
### Ficheiros do RF-AF-01
|
||||
|
||||
Migração `2026_10_28_000004`; modelo `ConflictDeclaration`; controlador `ConflictDeclarationController`; serviço `ConflictGuard`; integração em `RequisitionWorkflow`, `Requisition`, `RequisitionController` e `QuotationController`; rotas e menu; tipos `conflict.ts`, páginas `conflicts/index` e `conflicts/show` e avisos nas páginas de requisição/cotações; testes `ConflictDeclarationTest`; documentação de desenvolvimento e README.
|
||||
|
||||
## Entrega anterior de fornecedores e anexos
|
||||
|
||||
O registo abaixo conserva o estado e os resultados da entrega anterior. As referências a declarações de conflito como próximo passo dizem respeito a essa entrega e são substituídas pelo incremento RF-AF-01 acima.
|
||||
|
||||
## Incremento de 28 de Outubro de 2026
|
||||
|
||||
Edição e renovação de fornecedores e documentos privados, na base Laravel e React existente. As orientações de continuidade foram lidas nesta sessão. A inspecção inicial confirmou cadastro, validação e cotações já implementados; os novos recursos de edição e documentos ainda estavam ausentes. Não houve passagem para outro chat nem criação de outro projecto.
|
||||
|
||||
### Implementação
|
||||
|
||||
- Procurement pode editar a ficha e renovar a data da próxima revisão. Os campos são validados no servidor, incluindo NUIT único por empresa. Campos de propriedade, validação e estado enviados pelo navegador não são aceites.
|
||||
- Alterações efectivas devolvem o fornecedor a pendente, limpam a validação actual e registam o antes e depois na auditoria. Gravações sem alterações preservam a validação. As cotações existentes permanecem guardadas; a elegibilidade depende do estado actual do fornecedor.
|
||||
- Cada ficha tem versão. Edições e decisões de Finanças com uma versão antiga são recusadas. O criador e o último utilizador que alterou a ficha ou enviou documentos não podem validar o próprio trabalho, mesmo após mudança de perfil.
|
||||
- PDF, JPEG e PNG, entre 1 KB e 2 MB por ficheiro. O limite respeita o `upload_max_filesize=2M` do PHP local, sem alterar configuração global ou `.env`. O servidor verifica MIME, extensão e tamanho.
|
||||
- Documentos em disco dedicado `supplier_documents`, fora de `public` e fora do disco local com URLs assinadas. Caminhos internos não são enviados para a interface. Downloads autenticados e autorizados por empresa e perfil, com validação da ligação ao fornecedor, sem visualização inline e sem cache partilhada.
|
||||
- Apenas Procurement envia documentos. Administração, Procurement e Finanças da mesma empresa podem descarregar. Chefes consultam a ficha sem metadados ou downloads dos documentos; solicitantes e armazém não acedem à ficha.
|
||||
- Envios e downloads geram auditoria. Novos documentos invalidam a validação do fornecedor; os anteriores são preservados. Falhas da transacção removem o ficheiro recém-enviado e revertem os metadados e o estado.
|
||||
|
||||
### Ficheiros deste incremento
|
||||
|
||||
Migração `2026_10_28_000003_add_supplier_maintenance_and_documents`; `SupplierController`, `SupplierDocumentController`, `SaveSupplierRequest`, `SupplierPolicy`, modelos `Supplier` e `SupplierDocument`; disco em `config/filesystems.php`; rotas de fornecedores; tipos `supplier.ts` e páginas `suppliers/index`, `suppliers/edit` e `suppliers/show`; testes `SupplierMaintenanceTest` e adaptação da versão em `SupplierQuotationTest`.
|
||||
|
||||
### Verificação concluída
|
||||
|
||||
- Testes Laravel: 74 passaram, 3 ignorados, 447 asserções. Cobrem edição, versões antigas, renovação, validação independente, MIME/extensão/tamanho, permissões, isolamento entre empresas, ligação documento/fornecedor, downloads auditados e reversão quando falha a auditoria.
|
||||
- PHPStan sem erros; Pint aprovado; verificação frontend sem avisos ou erros; TypeScript e compilação aprovados; `git diff --check` sem erros.
|
||||
- Migração aditiva `2026_10_28_000003` aplicada no PostgreSQL local depois dos testes. Contagens anteriores e posteriores iguais: 1 utilizador, 1 empresa, 0 requisições, 0 fornecedores, 0 cotações e 0 avaliações; nova tabela de documentos vazia. Não foram executados seeds, criadas contas ou alteradas credenciais/configuração.
|
||||
- Entrada em http://127.0.0.1:8015/login confirmada com HTTP 200 e identificação ProcuraFlow; oito rotas de fornecedores registadas. As páginas autenticadas e as permissões foram verificadas nos testes Inertia; não foi feita inspecção visual autenticada no navegador.
|
||||
|
||||
As verificações funcionais usam SQLite em memória e armazenamento simulado, sem ficheiros ou registos de teste na base real. A migração é a única escrita realizada na base real neste incremento.
|
||||
|
||||
### Limitações e próximo passo
|
||||
|
||||
Não há eliminação/substituição de documentos, antivírus, quotas acumuladas ou política de retenção nesta entrega. O hash SHA-256 é registado na recepção; não constitui assinatura digital ou análise antivírus. A revisão visual autenticada depende da sessão existente; não pedir nem redefinir a palavra-passe para testar. Concorrência real em PostgreSQL requer testes com ligações simultâneas, além dos testes de versões e transacções.
|
||||
|
||||
Continuam pendentes dados bancários com dupla validação e cadastro de declarações de conflito; não considerar a ficha ou a diligência devida como conformidade integral com RF-AF-01, RF-AF-05 ou RF-AF-06. Próximo passo: declarações de conflito e, depois, adjudicação e ordens, mantendo os controlos e decisões provisórias descritos na especificação. Conta, credenciais, configuração e dados existentes devem continuar preservados.
|
||||
@@ -0,0 +1,145 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user