SGF/docs/PURCHASING_UPDATES_DELIVERY.md

Transferência de Compras e actualizações do SGF

Decisão de instalação — proposta sem execução, 02/11/2026

O âmbito escolhido pelo proprietário é decidir a instalação, sem a executar. A decisão concreta identifica projecto/base efectivos, candidata/hashes, schema/catálogos, bloqueantes e backup/restauro/recuperação. Os planos de leitura de código/schema passaram e o ZIP foi reconferido. O inventário do destino foi obtido em transacção PostgreSQL READ ONLY; nenhuma suite foi repetida.

Recomendação: não instalar esta candidata como percurso operacional ainda. O destino C:\laragon\www\sgf-tempo, base sgf_tempo_dev em 127.0.0.1:55432, tem 87 tabelas e usa sgf_dev_app, sem CREATE/ALTER necessários. Faltam a execução migradora/mapa de privilégios mínimos runtime e a preparação operacional de centros/dotações: não existem tabelas cb_*, a interface candidata apenas selecciona centros existentes e a interface orçamental actual depende de duas tabelas ausentes do schema candidato. As provas isoladas com role proprietária/cadastros preparados não cobriam esses aspectos do destino. Preservar o ZIP aprovado como evidência e resolver essas lacunas antes de propor a operação executável; novos bytes exigem novos hashes/provas.

Catálogo administrativo: implementado/testado na candidata, ainda não instalado; não é falta de implementação, mas não constitui direitos já atribuídos. Equipamentos/peças: fora do recorte básico de consumíveis/serviços/outros, não são o seu bloqueio. Há uma concessão de administração da empresa no destino; a regra de dois administradores permanece pendente para entrega/activação, sem criar conta ou atribuir direitos por conveniência. A eventual instalação técnica desactivada é diferente de abrir o percurso aos utilizadores.

Navegação modular: tecnicamente aceite em 02/11/2026, conforme registo próprio do SGF. Manter separadas revisão visual/recargas, associações antigas e volume/paginação. Essa aceitação não autoriza instalar a candidata, alterar direitos públicos ou publicar. O SGF continua em 0.1.1. Não foram executados migrate, apply, cache, backups, concessões, manutenção ou paragem/reinício de serviços.

Reconciliação com a entrega modular do SGF — 02/11/2026

A conferência documental posterior encontrou uma entrega própria de navegação modular no SGF: implementação e estado, conclusão técnica e conferência de 02/11/2026. Portanto, a indicação anterior «sem resultado apresentado» fica sucedida por «entrega técnica documentada, com encerramento pendente». Não repetir implementação ou testes já registados com base naquele estado histórico.

Segundo essa entrega, os módulos são Comercial, Compras, Stock, Oficinas, Financeiro e Contabilidade; Início e Opções gerais estão separados do módulo activo. A entrega regista 185 testes/3.220 asserções de regressão, 8 testes/90 asserções focados e três perfis sintéticos num ambiente próprio. A conferência registada comparou 184 ficheiros com a cópia validada, confirmou hashes de JUnit e preservação de concessões/pertenças/auditoria/guarda/ponteiro, sem repetir testes ou provisionamento. Esta retoma de Compras leu e reconciliou essas provas, não executou novamente essa conferência nem as suites. Instância isolada documentada: http://127.0.0.1:8039.

Continuam separados: revisão visual pendente, incluindo recargas de páginas autónomas; reconciliação humana das associações antigas; avaliação de volume/paginação antes de implantação. A interface usa «Opções gerais», não um submenu único literalmente chamado «Configuração». Não declarar aceitação visual, cobertura operacional dos módulos em preparação ou disponibilização comercial integral.

Esta entrega modular não instala a candidata de requisições nem substitui as suas provas de código/schema/caches. A integração candidata continua preparada e verificada no âmbito descrito abaixo; o SGF de destino permanece em 0.1.1. Não houve instalação, activação, alteração de código/permissões ou nova tentativa de navegador nesta reconciliação. A decisão de instalar continua separada, conforme instrução do proprietário.

Actualização entre bundles e caches nativos — 02/11/2026

Concluído neste incremento candidato: transição de código entre bundles já instalados, reversão para o anterior e compilação/recuperação dos caches Laravel nativos. 32 controlos novos aprovados, sem repetir as suites anteriores. Prova e hashes em proofs/sgf-update-cache-delivery.json. A candidata é OPERATIONAL-CANDIDATE-5fae7cf7f99c42ba, com ZIP de revisão; SHA-256 do ZIP d14a3261d5aaab80f96250af781c700ab53376021f4638e3aee43c15ff37ceed e do manifesto b1ec47f7a9ad87e0b232bac41e402d4a00ee5f03f00a79b93effc692ce8b39a2. Não foi publicado no canal, instalado ou activado no destino. SGF mantém 0.1.1.

As pendências históricas de transição entre versões e ensaio dos caches padrão, registadas nas secções seguintes, são sucedidas por este resultado. Não se altera o âmbito das provas anteriores nem se declara concluída a reorganização modular do SGF.

Transição com proveniência local

plan reconhece a versão de código seleccionada pelo registo privado storage/app/private/module-deployments/current.json, distinto do ponteiro packages/purchasing/current.json que permanece intacto. Confere o journal, os bytes e o manifesto do bundle instalado; rejeita alterações locais, conteúdo extra, bundle sem proveniência, mudança de baseline/composição dos ficheiros nativos ou diferenças nos ficheiros de preparação do schema/catálogo. A transição implementada cobre código sob o mesmo contrato de schema. Alterar esse contrato exige plano/revisão de migração próprios; não executa uma migração implicitamente.

apply guarda o bundle anterior na instalação, troca o código sob manutenção/serviços parados e actualiza atomicamente o registo privado da versão seleccionada. rollback repõe o bundle, ficheiros nativos e proveniência anteriores, sem depender da pasta de Compras, base de desenvolvimento ou ficheiros da origem. Recusa reversão fora de ordem e replay de uma versão que já não está seleccionada. Uma nova tentativa depois de uma reversão recebe outro ID; os journals anteriores permanecem preservados. A repetição de uma reversão já concluída não volta a alterar código/caches da versão anterior.

O registo privado é criado pela rotina actual. Uma cópia antiga/manual de bundle, sem esse registo, não é adoptada automaticamente: exige reconciliação explícita da proveniência. Este requisito preserva os ficheiros existentes e não atribui direitos funcionais. Continua a não haver outorga automática, alteração do perfil ou importação de dados de desenvolvimento.

Compilação nativa e recuperação de caches

A CLI tem agora a acção cache, que usa o mesmo PHP fixado para executar config:cache, route:cache e event:cache no próprio host, com manutenção/serviços parados. Arquiva os caches anteriores em armazenamento privado, invalida-os antes de arrancar Artisan e regista comandos/resultado/hashes dos ficheiros produzidos, incluindo resultados parciais quando uma compilação falha. Assim, um config.php truncado não impede a CLI de o preservar e reconstruir a configuração a partir das fontes actuais. Os logs e cópias compiladas ficam privados e não são incluídos no ZIP cliente.

Se tiver havido compilação registada, a reversão invalida esses caches e conserva-os em arquivo privado; não repõe silenciosamente valores compilados antigos sobre configuração posterior. Depois de repor o bundle anterior, executar cache para o ID dessa versão e reiniciar os seus serviços antes de reabrir. Se não tiver havido recompilação, mantém-se a reposição exacta dos caches anteriores já ensaiada. Alterações aos caches após a compilação registada continuam a bloquear uma reversão cega e exigem reconciliação. Caches com caminhos personalizados continuam fora do contrato actual e são recusados antes de aplicação/recuperação.

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-code-deploy.php" plan "<raiz-SGF>" "<candidata>" <manifest-sha256>
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-code-deploy.php" apply "<raiz-SGF>" "<candidata>" <manifest-sha256> <target-codigo-sha256> "<operador>" --offline
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-code-deploy.php" cache "<raiz-SGF>" <deployment-id-seleccionado> "<operador>" --offline
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-code-deploy.php" rollback "<raiz-SGF>" <deployment-id-a-reverter> "<operador>" --offline

Para uma actualização: conferir a origem aprovada, os hashes e o plano; preservar o destino e parar os serviços em manutenção; aplicar o bundle; compilar os caches para o ID devolvido; reiniciar apenas os serviços dessa instalação e conferir o seu arranque; reabrir só pela decisão de activação separada. Para reverter: parar serviços em manutenção, reverter o ID seleccionado, compilar os caches da versão anterior reposta e reiniciar/conferir antes de reabrir. Dados/schema/permissões não são restaurados por estes comandos. A preparação de schema continua no executor separado, apenas quando houver uma migração prevista e ensaiada.

Âmbito exacto das novas provas

Ensaiada transição real entre a candidata anterior 10dce6cd57fa1f31 e a nova, recuperação de falha entre preservação/troca dos bundles, reversão e nova tentativa com histórico distinto. Confirmadas recusas de origem desconhecida, schema divergente, alteração local/conteúdo extra e reversão fora de ordem. A segunda cópia inclui aplicação e dependências, sem .env ou dados reais; para acelerar o ensaio, as dependências imutáveis usam hardlinks apenas para uma cópia descartável anterior, nunca para o vendor do SGF de destino. Não se executam comandos Composer que alterem essas dependências.

Na cópia isolada foram executados os três comandos de cache nativos, falha injectada após config:cache, recuperação de cache inválido pela CLI e reinícios efectivos do servidor PHP local de teste. A rota em cache manteve autenticação (401 para anónimo), manutenção manteve bloqueio (503) e o host voltou a responder após reversão, sem a rota retirada (404) e com healthcheck 200. Os reinícios cobrem o servidor de teste, não certificam todos os gestores de serviços de clientes. Nenhum serviço, base, direito público ou ponteiro do SGF de destino foi alterado. Nenhuma contratação para terceiros foi incluída.

O ZIP contém código/manifesto locais com integridade conferida, sem base, credenciais, documentos, cache de cliente ou dependências copiadas de desenvolvimento. Pode ser transportado e extraído para uma pasta de preparação no cliente; conferir hashes e executar as ferramentas pelo PHP do próprio SGF. Não extrair directamente sobre a raiz do host. A aprovação do canal de confiança e a decisão de instalar/activar continuam separadas; a preparação do ZIP não é publicação ou autorização de implantação.

Aplicação e reversão offline do código — 02/11/2026

Implementadas integrations/sgf/operational/CodeDeployment.php e CLI scripts/sgf-code-deploy.php, incluídas na candidata OPERATIONAL-CANDIDATE-10dce6cd57fa1f31. 42 controlos novos aprovados com PHP 8.4.27 fixado do SGF, apenas sobre cópias descartáveis de ficheiros; sem abrir bases, reiniciar serviços ou repetir suites anteriores. Ver proofs/sgf-code-deploy-delivery.json. O SGF instalado continua em 0.1.1 e nenhuma aplicação/reversão foi executada nesse destino.

A rotina distingue plan read-only, apply e rollback. Confere manifesto e conteúdo, hashes anteriores dos ficheiros do host e impressão do destino, mantém lock exclusivo e prepara cópias anteriores em storage/app/private/module-deployments/<id>. O journal durável é escrito antes de começar a substituir código; cada ficheiro é preparado e trocado por rename no seu directório e o bundle é preparado separadamente antes da troca. Isto não é uma transacção de filesystem sobre todos os ficheiros: a consistência visível exige manutenção e serviços de escrita parados durante toda a implantação/recuperação. Uma interrupção deixa o journal para recuperação explícita, sem reabrir o serviço automaticamente.

apply exige manutenção Laravel baseada em storage/framework/down e --offline, que é a declaração do operador de que parou web/workers/schedulers responsáveis por escritas. A rotina não detecta nem termina processos. Guarda os caches padrão config.php, events.php, packages.php, services.php e routes*.php existentes em bootstrap/cache, invalida-os e preserva outros ficheiros. Os backups de configuração compilada podem conter segredos e ficam exclusivamente no armazenamento privado local, com permissões restritas do sistema; não integram o artefacto distribuído. Caches configurados por APP_*_CACHE fora das localizações padrão são recusados antes da aplicação: não são apagados nem presumidos cobertos.

rollback confere código, backup e caches antes de restaurar; recusa alterações locais desconhecidas e caches recriados, em vez de sobrescrever trabalho ou configuração posterior. Repõe os bytes anteriores dos ficheiros/caches e retira o bundle para arquivo privado de diagnóstico. Recupera igualmente aplicação interrompida a meio dos ficheiros ou depois da troca do bundle. Não apaga schema, dados, recibos de negócio, permissões ou operações posteriores. Conserva o ponteiro packages/purchasing/current.json e deixa manutenção activa. A existência de restart_required=true é uma obrigação operacional, não prova de reinício automático.

Sequência de implantação, após decisão separada

1. Produzir/conferir a candidata e manifesto por canal de confiança. Executar plan de schema e plan de código e registar as duas impressões de destino. Conferir o destino e preservar dados/documentos/configuração. A rotina de código não substitui o backup/restauro de PostgreSQL.
2. Entrar em manutenção pelo procedimento do host (artisan down, driver de ficheiro) e parar os serviços de escrita daquela instalação. Não usar comandos de demonstração que também parem outras instalações. Não executar apply com serviços em funcionamento.
3. Executar a preparação de schema sgf-internal-install.php migrate, com backup/manifesto/destino conferidos, conforme secção própria. Nenhuma concessão é atribuída por essa preparação.
4. Executar sgf-code-deploy.php apply com o hash do manifesto, impressão do plano de código, operador nominativo e --offline. Registar deployment_id. A rotina confere e aplica apenas código/bundle e invalida caches conhecidos; não activa configuração comercial nem concede direitos.
5. Mantendo a manutenção, conferir os ficheiros e o journal, configurar explicitamente o destino/âmbitos e os acessos aprovados pelo percurso administrativo, e reiniciar os processos persistentes pelo gestor de serviços daquela instalação para descartar código/opcache antigo. A atribuição administrativa que requer HTTP terá de usar uma janela controlada depois do arranque; não contornar os middlewares nem inserir concessões por SQL para evitar essa etapa. Remover a manutenção e abrir aos utilizadores só depois de conferir a instalação e da decisão de activação. Estas acções de serviços/configuração/abertura são do operador e não são executadas pela CLI.
6. Em falha de código, manter/parar novamente os serviços em manutenção, executar rollback com o ID registado, conferir a reposição, reiniciar os serviços e só então decidir reabrir. Se houver código ou caches alterados depois da aplicação, a rotina recusa a recuperação: preservar esses estados e reconciliar explicitamente antes de tentar novamente. Não executar down de migrações nem restaurar backup de dados por efeito de rollback de código.

CLI pelo PHP fixado do host; exemplos com parâmetros, não executados no SGF de destino:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-code-deploy.php" plan "<raiz-SGF>" "<candidata>" <manifest-sha256>
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-code-deploy.php" apply "<raiz-SGF>" "<candidata>" <manifest-sha256> <target-codigo-sha256> "<operador>" --offline
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-code-deploy.php" rollback "<raiz-SGF>" <deployment-id> "<operador>" --offline

Limites exactos: esta versão cobre primeira instalação sobre o baseline conferido e recusa um bundle já existente ou ficheiros nativos divergentes. Ainda não implementa transição entre versões do novo bundle; o updater anterior de código 0.1.1 conserva apenas o seu âmbito já demonstrado. Os controlos de caches deste incremento verificam invalidação e restauro byte a byte dos ficheiros padrão, não regeneração de todos os caches em Laravel nem automação de gestores de serviços. A prova HTTP anterior de 27 controlos mantém o seu âmbito; não foi repetida sobre cada combinação de caches. Não declarar disponibilização comercial completa nem aceitar actualizações futuras sem a respectiva transição/compatibilidade. A reorganização modular permanece entrega distinta.

Arranque e integração HTTP em cópia isolada — 02/11/2026

Preparada a candidata OPERATIONAL-CANDIDATE-4b25f81932efd69d, preservando os artefactos anteriores. A composição já inclui sobreposição do provider nativo para carregar o bundle local e registar as rotas, sem registo manual de rotas pelo harness HTTP. O bundle fica em packages/internal-requisitions, com classes e ficheiros próprios; a sobreposição do SGF reconhece purchasing_requisitions.view como autorização de descoberta do módulo Compras, sem conceder direitos nem substituir o catálogo/controlo funcional.

RuntimeContext é acrescentado às rotas do bundle depois dos middlewares nativos de sessão/autenticação/empresa. Confere opção operacional habilitada, destino/schema/âmbito, módulos adquiridos e habilitados, selecção explícita de Compras e geração de contexto nos APIs. A atribuição inicial permanece no âmbito de Administração: não exige um direito funcional de requisição que ainda não foi outorgado, mas exige módulo adquirido, âmbito habilitado e os controlos nominativos/administrativos já implementados. Não cria autoridade a partir da selecção do módulo. A composição desactivada recusa a execução das rotas.

O ensaio scripts/sgf-composition-proof.php usa uma instalação descartável com código, dependências e packages copiados, provider/configuração/rotas do próprio SGF e bootstrap nativo, sem .env, contas, documentos ou dados empresariais copiados. Usa base sgc_composition_<12hex> e role próprias, ambiente production, sessões privadas e acesso HTTP loopback com login/CSRF reais. A preparação de dados sintéticos e a activação ocorrem exclusivamente nessa cópia/base; não são passos aplicados ao SGF de destino. O router de teste só entrega o pedido ao kernel: não regista rotas, não substitui autenticação e não carrega classes da instalação original.

Resultados efectivos, caminho do artefacto e verificações em proofs/sgf-composition-delivery.json. A prova verifica o incremento de composição/HTTP, incluindo autoridade inicial, administração nativa, contexto, submissão/reserva/aprovação/consulta e revogação; não repete as suites anteriores nem declara revisão visual por navegador. Os resultados históricos seguintes conservam o seu âmbito.

Resultado final: 27 controlos novos aprovados. Confirmados provider e adaptador efectivamente carregados da cópia isolada; plan aceite pelo verificador de integridade do novo bundle; acesso anónimo e CSRF bloqueados; autoridade inicial sem direitos funcionais prévios; atribuição pela administração nativa; selecção explícita de Compras; recusa de token antigo, modalidade diferente, revogação, módulo não adquirido e composição desactivada; rascunho → submissão com uma reserva existente → aprovação por outra identidade → consulta com três versões/eventos. Base e role descartáveis removidas. Nenhum registo de dados ou direito do SGF de destino alterado.

Limites de entrega: esta composição ainda não foi aplicada ao destino. Falta a rotina operacional de aplicação atómica das sobreposições/código, preservação/reversão dos ficheiros do host e gestão dos caches/reinício de serviços. O ensaio usa configuração sem cache; não declara validada a activação com cache de rotas/configuração pré-existente. As alterações de configuração da prova foram seguidas de reinício do serviço PHP. plan/migrate continuam a preparar/conferir schema, sem aplicar estas sobreposições ou activar rotas. Não substituir esse procedimento por extracção cega do bundle. SGF de destino mantém 0.1.1, sem schema, permissões, provider ou rotas alterados. Activação continua dependente da decisão separada. A reorganização modular posterior é uma entrega distinta, não concluída por este incremento.

Objectivo e estado em 01/11/2026

O foco autorizado pelo proprietário é transferir as capacidades de Compras para o SGF e levar as melhorias seguintes por versões verificáveis. Não é sincronizar bases de desenvolvimento nem manter duas implementações. O SGC autónomo conserva todas as suas funcionalidades; no SGF, Pessoas e contratações destina-se apenas ao uso interno. Cada cliente recebe as capacidades adquiridas, com configuração e permissões próprias.

Implementado neste incremento: mecanismo de publicação/instalação/actualização/reversão e primeira capacidade realmente extraída e executada no SGF: projecção de reposição de stock. A transferência integral dos processos, ecrãs, identidade e dados de negócio ainda não está concluída.

Conferência antes de ampliar, 01/11/2026: a prioridade passa a ser esta matriz e a delimitação de instalação/reversão, conforme pedido posterior do proprietário. SGF local activo em 0.1.1. O núcleo económico começou a ser preparado antes desse pedido; a transferência em curso foi interrompida antes de nova activação. Existe candidata 0.1.2 no canal, sem instalação no SGF. Código preparado na origem não conta como capacidade transferida.

Actualização posterior autorizada: percurso de requisição interna implementado como candidata de revisão IR-CANDIDATE-bfa807e2b3c4fae7, testada sem activar o destino. A matriz abaixo distingue essa implementação candidata da capacidade instalada. Ver detalhes, recuperação e limites na secção do percurso escolhido.

Fonte única e fronteira dos dois hosts

packages/purchasing em Compras é a fonte canónica. App\Services\ReplenishmentProjection passou a fachada de compatibilidade; os consumidores actuais conservam a assinatura e usam o motor comum Tempo\Purchasing\Supply\ReplenishmentProjection. O SGF carrega os mesmos bytes de uma pasta de versão instalada. Não há chamada HTTP a Compras, procura da pasta vizinha, segundo algoritmo ou alteração das dependências instaladas.

As diferenças concretas que impedem uma cópia directa da aplicação permanecem: SGF usa tenant/empresa fiscal/unidade e concessões/contexto próprios, enquanto Compras usa tenant/departamento e perfis; ambos têm classes App e tabelas-base com significados diferentes. Os frontends e versões de PHP/Brick Math também diferem. Não copiar os controladores, tabelas users/tenants ou histórias de migração de um host para o outro. Extrair capacidades e adaptar contexto/acesso explicitamente.

Matriz de integração conferida

Estados: Transferido identifica a capacidade exacta instalada e executada no SGF; Parcialmente transferido identifica componentes comuns existentes, com lacunas no percurso; Pendente identifica capacidades ainda não incorporadas no SGF. A presença de um menu, cálculo ou classe não comprova transferência do processo completo. Capacidades excluídas do SGF são identificadas à parte.

Processo/capacidade	Estado	Núcleo e persistência	Adaptadores de identidade/acesso e integração	Ecrãs e percurso no SGF	Evidência/lacuna determinante
Publicação, instalação e actualização de código do pacote	Transferido	Artefactos imutáveis, hashes, lock, histórico e ponteiro local; sem schema	CLI local e prova com PHP do host; sem alteração de direitos	CLI implementada; painel de updates não implementado	0.1.0/0.1.1, retry e rollback de código conferidos; migrações e canal remoto assinado pendentes
Cálculo de projecção de reposição	Transferido	Mesmo motor de consumo manual, média racional, reservas/entregas e lotes; sem persistência própria	Carregamento local independente do checkout de Compras; não concede acesso a dados	Sem novo ecrã; capacidade de cálculo instalada	Pacote activo 0.1.1, dois testes SGF e prova de cliente independente
Orçamento de Compras no núcleo comum	Parcialmente transferido	packages/budget-control comum anterior; mesmo motor de reserva	Composição operacional candidata com destino/schema/âmbito explícitos; adaptador instalado continua QA	Interface anterior e candidata de requisições; arranque/rotas operacionais ainda não integrados	20 controlos novos de preparação; restauro em production/base fora do prefixo QA verificado; sem instalação/activação no destino
Preparação de schema da integração	Parcialmente transferido — candidata não instalada	Migração transaccional, contrato do orçamento, registo imutável de revisão/hashes/operadores/backup	CLI plan/migrate local ao host, sem cópia de dados sintéticos ou concessões	Sem ecrã ou activação implícita; CLI de preparação não substitui instalação de código/rotas	Prova nova sgf-operational-delivery.json; destino 0.1.1 preservado
Aplicação/actualização/reversão do código da nova integração	Parcialmente transferido — candidata não instalada	Journal/backups e registo privado da versão, lock, preservação do bundle anterior; sem efeitos de dados/schema	CLI plan/apply/cache/rollback, com proveniência e contrato de schema iguais; serviços parados pelo operador	Transição, falhas e reversão ensaiadas; caches nativos compilados e servidor isolado reiniciado; nenhuma abertura automática no cliente	32 controlos novos em sgf-update-cache-delivery.json, além das provas anteriores; caches personalizados e migrações futuras exigem plano próprio; destino 0.1.1
Factura conferida → obrigação a fornecedor	Parcialmente transferido	Núcleo comum de obrigações anterior, com origem única	Adaptador SGF e API no âmbito sintético; sem passagem automática de tabelas/IDs de Compras	Consulta/decisão do percurso anterior; sem workflow integral de recepção/conferência de facturas de Compras	SupplierPayables conserva guarda de ensaio; fornecedor de histórico SGF não concluído conforme entregas anteriores
Pagamentos e afectações a fornecedores	Parcialmente transferido	Núcleo comum e entregas anteriores preservados	Adaptadores/autorizações delimitados nas respectivas entregas; não representam migração de contas ou histórico de cliente	Percurso anterior existe no âmbito documentado; integração completa com novas origens de Compras pendente	SUPPLIER_SETTLEMENT_DELIVERY.md e limites de histórico/origens; não afirmar financeiro integral
Identidade, empresa/unidade, perfis e módulos adquiridos	Parcialmente transferido	Fundações próprias existentes nos dois hosts; não se fundiram tabelas-base	SGF mantém tenant/empresa fiscal/unidade/concessões; correspondência explícita com o contexto Purchasing por concluir	Sessão/contexto SGF existentes; selector SGC não foi incorporado automaticamente	Sem associação por igualdade de nome, email ou ID; parametrização comercial e permissões continuam distintas
Navegação modular do SGF, entrega própria	Tecnicamente aceite — 02/11/2026	Seis módulos, Início/Opções gerais separados; não equivale a todos os processos comerciais concluídos	Provas SGF próprias de contexto, autorização e perfis sintéticos; sem outorga adicional por escolha de módulo	Revisão visual/recargas, associações antigas e volume/paginação mantêm pendências próprias	Aceitação expressa em MODULAR_NAVIGATION_DELIVERY/COMPLETION; 185 testes/3.220 asserções preservados; não autoriza a instalação da candidata
Requisição interna: rascunho, submissão, aprovação independente e consulta	Parcialmente transferido — candidata; não activa	Motor único InternalRequisitions, adaptadores dos dois hosts; recibos, versões e histórico; reserva existente na mesma transacção	Contexto interno, empresa/unidade, autorização renovada e identidade independente; composição no provider e associação do novo direito de consulta ao módulo preparadas	Ecrãs e percurso integrados na cópia isolada pelo arranque nativo; nenhuma rota/menu novo activo no destino	Provas anteriores preservadas; novo ensaio de composição HTTP em sgf-composition-delivery.json; aplicação operacional do código/caches e equipamentos/peças pendentes; destino 0.1.1
Planeamento de compras	Pendente	Itens, marcos e associação a requisições permanecem em Compras	Adaptar unidades, centros, intervenientes e vínculos de origem no SGF	Planeamento e acompanhamento de marcos SGF do roteiro de Compras pendentes	Não gerar requisições duplicadas nem inferir reserva/decisão a partir de um plano
Fornecedores, documentos e dados bancários	Pendente	Cadastros/versionamento de Compras ainda não extraídos	Definir correspondências autorizadas de fontes e permissões, sem fundir entidades por nome	Cadastro, validações e consulta SGF de todo o percurso pendentes	Preservar fotografias utilizadas e validação bancária independente
Cotações, descontos e comparação económica	Pendente	Descontos e pontuação foram preparados na origem/candidata 0.1.2; SGF activo não contém estas classes	Elegibilidade, conflitos, avaliações autorizadas e decisão continuam no host; adaptador do processo SGF não implementado	Recepção de cotações, grelha, empates, recomendação e decisão SGF pendentes	Testes locais não equivalem a transferência. Candidata não instalada; nenhuma adjudicação automática
Abertura, admissibilidade, qualificação, recomendação e adjudicação	Pendente	Serviços/snapshots permanecem em Compras	Traduzir contexto, atribuições, impedimentos e versões sem alterar decisões concluídas	Actas, avaliações, decisões e ordens ainda não incorporadas	Necessita persistência e percurso completo por etapa, não simples ligação de menus
Ordens, recepções, inventário físico e lotes	Pendente	O cálculo de reposição está transferido; movimentos, ledger físico, decisões e reversões não	Adaptar origens únicas, armazéns/artigos, separação de funções e âmbito empresarial	Guias, recepções, saídas, transferências, contagens e lotes SGF de Compras pendentes	Não duplicar efeitos físicos ou confundir projecção com stock disponível
Fornecimento habitual, sugestões e importações	Parcialmente transferido	Apenas o motor de projecção incorporado; acordos, políticas versionadas, conversões e logística pendentes	Fontes, decisões, cadastros e vínculos aos processos SGF ainda por adaptar	Calendário, sugestão → requisição e importação operacional SGF pendentes	Um cálculo disponível não completa o workflow de abastecimento
Equipamentos, peças, manutenção e investimento	Pendente	Serviços/cadastros de Compras ainda não incorporados	Correspondência de activos/peças/unidades e regras aprovadas por definir tecnicamente	Ecrãs/percursos de Compras no SGF pendentes	Preservar origens e não repetir consumo físico/custo
Avaliação de fornecedores, melhoria e contraditório	Pendente	Versionamento, decisões e evidências permanecem em Compras	Adaptadores de intervenientes, conflitos e autorização independente pendentes	Preparação, revisão, acompanhamento e relatórios SGF pendentes	Não alterar avaliações antigas nem confundir qualificação com desempenho
Relatórios de Compras e sínteses factuais	Pendente	Projecções autorizadas de Compras ainda não extraídas	Reutilizar âmbito efectivo e versões do processo no SGF	Relatórios individuais/consolidados do roteiro de Compras pendentes	Não substituir por relatórios financeiros SGF de outro âmbito; núcleo factual independente de IA
Venda de mercadorias e ligação ao comercial SGF	Pendente	A opção de contexto não é um percurso completo de retalho/grosso demonstrado em Compras	Reutilizar responsabilidades de stock/facturação SGF, sem criar motores ou efeitos concorrentes	Percurso conjunto por módulos adquiridos ainda por demonstrar	Não confundir aquisição para revenda com venda efectuada nem declarar emissão fiscal transferida
Pessoas: recrutamento e prestadores internos	Pendente	Processos e versões ainda em Compras; fronteira técnica de RH apenas preparada	Adaptar perfis/atribuições e integração futura com RH; apenas contrato formalizado pode desencadear ligação	Candidaturas, avaliações, decisões e formalização/RH no SGF pendentes	RH ainda não implementado; selecção aprovada/rascunho não criam vínculo

Fora do âmbito SGF: recrutamento e contratação de prestadores por conta de terceiros. Mantêm-se no SGC autónomo; não são uma pendência a implementar no SGF. Não transferir candidaturas automaticamente para Compras, vendas ou RH.

Percurso escolhido e candidata de requisições internas

O proprietário autorizou requisição interna → submissão → aprovação independente → consulta do processo, usando a reserva orçamental existente. A implementação está preparada separadamente para revisão. O SGF continua em 0.1.1; nem a candidata económica 0.1.2 nem esta integração foram activadas. Não foram publicados pacotes nem alterados direitos públicos.

O motor packages/purchasing/src/InternalRequisitions.php é usado pelo adaptador autónomo app/Services/InternalRequisitionPort.php e pela candidata integrations/sgf/internal-requisitions. Conserva as regras de valores, limites, reserva antes da submissão e decisão por identidade diferente do requerente e dos decisores anteriores. O adaptador SGF reutiliza CompanyContext, Permissions e BudgetAdapter; não copia utilizadores, empresas ou o motor orçamental.

A candidata inclui rascunho/edição, listagem, submissão, decisão e consulta com histórico, além de parametrização versionada de centros/departamentos/intervenientes/limites. Apenas centros e pessoas autorizados do host podem ser associados. A configuração habilita a opção interna; não atribui permissões. O servidor volta a validar direitos e contexto em cada operação, incluindo repetições, e projecta as acções disponíveis para os ecrãs. Chave de operação, hash do conteúdo, versão esperada, locks e transacção única preservam origem e impedem duplicação de requisições/reservas em retry e concorrência. Uma falha mantém a transacção anterior; uma resposta perdida admite a repetição da mesma operação.

Os artefactos de revisão são produzidos por php scripts/build-internal-requisition-candidate.php. O manifesto, hashes e caminhos estão em proofs/internal-requisitions-candidate.json. runtime.zip contém código e schema explicitamente não instaláveis pelo updater actual; verification.zip contém as provas. Não levam bases, dados sintéticos, credenciais, dependências ou concessões. O caminho do SGF serve apenas para preparar/verificar; o runtime candidato utiliza ficheiros locais e serviços do próprio host. A futura instalação exige uma entrega compatível com schema, separada da activação do ponteiro de código.

Limitações da candidata: SGF suporta neste recorte consumíveis, serviços e outros; equipamentos/peças e respectivas validações técnicas continuam apenas no percurso autónomo. Fornecedores, cotações, ordens e recepções não foram incorporados por arrasto. As rotas/ecrãs só são carregados pelo bootstrap explícito das provas; não há novo menu activo no destino. A integração do catálogo privado de permissões na administração comercial, a instalação/migração operacional e a parametrização comercial integral permanecem pendentes. A guarda isolada do adaptador orçamental SGF foi preservada. Não há integração de contratações para terceiros nem activação de RH.

Classificação das pendências para decidir a instalação

Incremento posterior de preparação dos acessos: o catálogo e a autoridade inicial já têm implementação candidata em integrations/sgf/access, preparada separadamente em ACCESS-CANDIDATE-a69f06e21747228a. Prova proofs/sgf-access-delivery.json: 24 controlos novos, em PostgreSQL descartável, sem repetir as suites aprovadas da requisição. O SGF instalado continua com o catálogo anterior. As classificações abaixo mantêm-se bloqueantes até integrar e instalar esta preparação com o orçamento/schema/arranque operacionais; não significam ausência de implementação candidata.

Conferência de código posterior à entrega, sem repetir testes aprovados e sem alterar a candidata congelada ou a instalação SGF. A candidata comprova o percurso em ensaio isolado; ainda não é uma entrega operacional instalável.

Pendência	Classificação para este percurso	Impacto e condição de resolução
Equipamentos/peças e validações técnicas	Fora do âmbito do percurso básico entregue	O adaptador SGF aceita consumable, service e other. Estas requisições podem completar rascunho → submissão/reserva → aprovação → consulta sem equipamentos/peças. Uma necessidade de equipamento/peça continua sem percurso SGF suportado; não deve ser disfarçada como other. A classificação não declara suporte a todos os tipos de requisição.
Catálogo administrativo das novas permissões e sua gestão	Bloqueante para este percurso em utilização operacional	Permissions::UNIT contém apenas unit.view e unit.edit; IdentityWorkflow::accessList/changeAccess filtra/valida esse catálogo. Os direitos purchasing_requisitions.* não podem ser atribuídos/revogados pela administração normal. As concessões directas dos testes foram apenas sintéticas e não constituem configuração comercial entregue.
Autoridade inicial para gerir/outorgar os novos direitos	Bloqueante para este percurso em utilização operacional	changeAccess exige que quem concede já possua o direito concedido. Acrescentar nomes ao catálogo não resolve a atribuição inicial: é necessária entrega nominativa, explícita e auditada da autoridade aprovada pela empresa, sem outorga automática aos perfis actuais. A listagem e revogação de direitos derivados da unidade também devem abranger o catálogo integrado.
Adaptador orçamental operacional	Bloqueante para este percurso em utilização operacional	BudgetAdapter::guard() exige ambiente budget-testing, PostgreSQL local e base budget_core_sgf_<12hex>. O adaptador de requisições chama essa guarda inclusive na consulta/configuração. Não basta copiar ficheiros ou permitir requisições sem orçamento. Substituir a composição exclusiva de ensaio por composição operacional configurada, mantendo autorização, isolamento e motor comum; não renomear base real nem mudar o ambiente para contornar a guarda. Os direitos orçamentais necessários também não integram o catálogo administrativo actual.
Instalação/migração, arranque e encaminhamento das rotas	Bloqueante para este percurso em utilização operacional	Schema::install e bootstrap existem, mas só foram compostos no harness isolado. Falta instalador operacional com pré-condições, registo de migração e recuperação, composição local e registo controlado de rotas. O updater actual recusa esta candidata; não é possível instalar o percurso com o comando habitual de update de código.
Fornecedores, cotações, ordens, recepções e contratações para terceiros	Fora do âmbito desta entrega	Não são necessários para terminar a requisição no estado aprovado e consultá-la; contratação para terceiros permanece excluída do SGF.

Direitos que a instalação deve permitir gerir, sem os conceder implicitamente: por empresa/unidade, purchasing_requisitions.view, .prepare, .configure, .approve.department_head, .approve.procurement e .approve.finance. Mantêm-se company.view, pertença à empresa e unit.view como condições do contexto. Submeter com reserva exige ainda purchasing_budget.record; rejeitar com libertação também usa esse direito existente. Preparação/aprovação da dotação usa os direitos do orçamento existente e deve ter responsáveis expressamente configurados. Só os escalões aplicáveis à política precisam de decisores, sempre com identidades distintas do requerente e dos decisores anteriores. Não é necessário conceder todos os direitos a todos os utilizadores.

Implementação candidata do catálogo e autoridade inicial

php scripts/prepare-sgf-access.php <raiz-SGF> lê os dois ficheiros de identidade do host e produz uma sobreposição de revisão em storage/app/private/candidates/ACCESS-CANDIDATE-<hash>, com manifesto e hashes antes/depois. Não escreve na pasta SGF, não aplica schema nem concede direitos. Recusa preparar uma alteração se os pontos esperados no host divergirem, exigindo reconciliação do trabalho em curso. A candidata original IR-CANDIDATE-bfa807e2b3c4fae7 não foi reescrita.

Na sobreposição, o catálogo unitário inclui os direitos de requisição e orçamento existentes; a criação de unidades continua a outorgar apenas unit.view/unit.edit. A administração nativa passa a listar/atribuir/revogar os novos direitos, conservando a exigência de o administrador possuir o direito que outorga. A atribuição unitária exige consulta da unidade pelo destinatário. Revogar a consulta da unidade confere autoridade sobre todos os direitos derivados afectados antes de os remover numa transacção; uma recusa não elimina parcialmente acessos.

InitialAuthority.php resolve a atribuição inicial como operação explícita. Exige administrador autenticado com access.manage, consulta/pertença ao contexto e uma lista de âmbitos habilitados pela futura composição de instalação (purchasing-access.initialisation_scopes, chaves tenant:company:unit; vazia por omissão). Só admite como destinatários administradores nominativos já autorizados nessa empresa/unidade. Escolhem-se os direitos e um fundamento, sem selecção automática de todos os direitos. Não atribui perfis de desenvolvimento. A concessão e a auditoria nativa purchasing.access_initialised são atómicas, serializadas pela empresa. Uma falha de auditoria desfaz as concessões. Uma repetição exacta não concede de novo nem recupera direitos entretanto revogados; outra inicialização é recusada, seguindo-se a gestão normal de acessos. Revogar a autoridade administrativa bloqueia também a consulta do ecrã e a repetição da operação.

As rotas candidatas em integrations/sgf/access/routes.php oferecem o ecrã /purchasing/internal-requisitions/access-initialisation e a operação /api/internal-requisitions/access-initialisation, com os middlewares nativos de autenticação, sessão e empresa. O ecrã mostra o contexto, permite escolher um destinatário nominativo e os direitos e envia CSRF/token de contexto/chave estável de operação. Estas rotas não estão registadas no destino. A prova nova verificou serviços nativos, persistência, autorização e renderização do ecrã; não declara ensaio HTTP completo ou revisão visual deste novo ecrã. A composição de instalação deverá ligar estas rotas ao módulo autorizado e retirar a habilitação de inicialização depois da entrega, preservando a auditoria.

Próxima dependência concreta: preparar a composição orçamental operacional e o instalador rastreável, incorporar esta sobreposição ao pacote SGF específico e conferir a sua integração HTTP. Não activar o módulo, a candidata de acessos ou 0.1.2 por consequência desta implementação.

Procedimento de instalação: estado exacto e sequência obrigatória

Incremento posterior — composição orçamental e preparação de schema: implementados em candidata separada integrations/sgf/operational e scripts/sgf-internal-install.php. Já existe executor de preparação de schema, com plan e migrate; continua sem existir comando completo de instalação/activação de código e rotas. Esta actualização sucede à ausência de executor registada na primeira conferência, preservando o âmbito das provas anteriores. Ver proofs/sgf-operational-delivery.json. Nenhum destes comandos foi executado na base da instalação SGF de destino.

php scripts/prepare-sgf-operational.php <raiz-SGF> lê o host e produz OPERATIONAL-CANDIDATE-<hash>, com manifesto, sobreposições de identidade/orçamento e ficheiros de suporte locais. Não escreve no SGF nem publica um pacote. A sobreposição orçamental conserva o motor e autorizações existentes; acrescenta composição operacional habilitada explicitamente, sem depender de APP_ENV=budget-testing ou de um nome de base QA. A guarda exige impressão do destino real (configuração e endereço/porta PostgreSQL efectivos), schema/versão de migração conferidos e âmbito tenant:company:unit autorizado em purchasing-operational.scopes. purchasing-operational.enabled é falso por omissão e purchasing-operational.target deve coincidir com o destino conferido. A guarda de ensaio anterior permanece para a composição QA, sem se tornar uma autorização operacional alternativa.

A preparação exige fundação de identidade existente; cria o schema orçamental vazio se ausente, ou confere o schema completo existente contra o contrato estrutural aceite, conservando registos e dotação aprovada. Schema parcial ou incompatível é recusado. Estende os valores unitários aceites pelo constraint de permissões sem conceder direitos. Aplica o schema de requisições e grava sgc_installations imutável, revisão 1, assinatura estrutural, hash da migração, backup, operador nominativo de implantação e role PostgreSQL executante. Usa lock transaccional de instalação e DDL transaccional. Repetição com a mesma migração/schema reconhece a preparação anterior; alterações divergentes são recusadas sem sobrescrever. Não há down nem eliminação de dados no executor. A revisão actual não é mecanismo genérico para futuras migrações; estas exigem novo plano compatível e revisão própria.

Procedimento da CLI na candidata, pelo PHP fixado do host, apenas depois da decisão de instalação e preservação do destino:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-internal-install.php" plan "<raiz-SGF>"
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<raiz-SGF>/scripts/sgf.ps1" php "<candidata>/scripts/sgf-internal-install.php" migrate "<raiz-SGF>" <target-sha256> "<backup.dump>" <backup-sha256> "<operador-nominativo>" <manifest-sha256>

plan só lê/verifica: integridade dos ficheiros da candidata, compatibilidade dos ficheiros do host com hashes antes/depois, identidade do destino, hash do manifesto e existência do registo de preparação. O campo schema_prepared informa a existência da tabela de registo; não substitui a conferência integral feita por migrate/guarda operacional. Conferir o manifesto/hashes com a referência de entrega por canal de confiança. migrate exige correspondência do destino e do manifesto, ficheiro de backup existente e SHA-256 coincidente; lê o índice com pg_restore --list antes de escrever. O cliente PostgreSQL deve estar no PATH ou indicado por PG_RESTORE_BINARY. Conferir o índice não prova recuperação: manter o restauro/reconciliação já aceites e o ensaio adicional da preparação operacional registado na prova. Nenhuma credencial deve ser passada nos argumentos ou copiada para o manifesto; usa-se a ligação configurada do próprio host.

Prova deste incremento: OPERATIONAL-CANDIDATE-29687a1c9bc0e0b5, 20 controlos novos aprovados, incluindo CLI real, backup custom válido, recusa de backup não conferido, schema vazio/existente/parcial/incompatível, falha injectada, recuperação da transacção, repetição sem novo registo, ausência de concessões e preservação do orçamento aprovado. Após backup/restauro para outra base descartável fora de budget_core_sgf_*, a mesma composição passou em production, conferindo schema/registo de preparação, reserva existente e revogação preservada. Este ensaio verifica o novo registo/schema operacional; não repete nem substitui as suites já aprovadas da requisição. As duas bases e role restrita foram removidas; o backup sintético não integra a entrega. Os caminhos e resultados estão em proofs/sgf-operational-delivery.json. Os ficheiros de código/ponteiro e dados do SGF instalado não foram alterados.

Após migrate, o estado é preparado, não activado: não altera o ponteiro 0.1.1, providers/rotas, concessões, dados de demonstração ou configuração de activação. O código/sobreposições candidatos ainda precisam de aplicação controlada, composição de arranque e integração HTTP antes de propor a activação. A configuração comercial por empresa/unidade e a atribuição explícita de acessos continuam obrigatórias. Isto não entrega fornecedores, consumo de facturas, pagamentos, equipamentos/peças ou reorganização modular do SGF.

Não há neste momento um comando operacional completo para instalar esta candidata. Os passos abaixo distinguem o que existe do que falta implementar; não são autorização para os executar no destino. A decisão de instalação continua separada. Não usar purchasing:transfer, purchasing-release.php install, os scripts de prova ou as fixtures para instalar esta integração numa empresa. O pacote runtime.zip é um artefacto de revisão, não deve ser extraído sobre a raiz do SGF: inclui também adaptações app/* de Compras que não pertencem ao host SGF.

1. Identificar e conferir — disponível: fixar a candidata IR-CANDIDATE-bfa807e2b3c4fae7, o manifesto e os hashes em proofs/internal-requisitions-candidate.json; conferir o ZIP e cada ficheiro contra o manifesto. Registar raiz/destino, PHP do wrapper SGF, versão de aplicação/dependências, servidor/base/empresa/unidade e estado do ponteiro packages/purchasing/current.json (actualmente 0.1.1). Confirmar que os pré-requisitos de identidade e orçamento correspondem à composição pretendida. Nenhum comando desta etapa migra ou concede direitos.
2. Preparar a entrega operacional — bloqueado pelas implementações identificadas acima: produzir pacote SGF separado e versionado apenas com os ficheiros comuns necessários e adaptadores/ecrãs do host; incluir migração rastreável, composição operacional do orçamento, catálogo/gestão dos direitos e mecanismo de autoridade inicial. Conservar os hashes da candidata como referência; uma alteração de código origina outro artefacto, sem sobrescrever o congelado. A migração 46 de Compras não se aplica à base SGF. Não copiar tabelas base nem fixtures de Compras.
3. Preservar o destino — procedimento necessário antes de qualquer futura escrita: suspender tráfego de escrita e workers, aguardar transacções em curso, registar instante de corte, arquivar código/configuração de implantação e ponteiro/histórico; preservar documentos/ficheiros e contas. Fazer backup integral PostgreSQL da base conferida, não apenas das tabelas ir_*, pois o orçamento e as concessões também são afectados. Guardar o arquivo, hash e identidade do destino fora do pacote distribuído. Não incluir segredos no registo de implantação.
4. Aplicar schema e preparar código sem expor rotas — executor de schema agora em candidata: usar a CLI plan/migrate descrita acima, sem outorgar acessos. O wrapper transaccional regista revisão, confere repetições e recusa divergências; não executar Schema::install isoladamente. Preparar os ficheiros num directório local de versão, sem sobrepor os app/* de Compras nem trocar para 0.1.2. A aplicação das sobreposições e o arranque/activação do código continuam separados e pendentes.
5. Configurar acessos e política — bloqueado pelo catálogo/autoridade inicial: pelos mecanismos administrativos auditados, atribuir explicitamente os direitos aprovados a pessoas nominativas e ao âmbito correcto; garantir requerente e aprovadores distintos, e responsáveis da dotação. Depois configurar centros existentes, referências de departamento, intervenientes, limites, inclusão de imposto e exigência de orçamento. Nenhum nome ou ID de outra instalação é uma correspondência automática. Não inserir concessões por SQL como solução de entrega.
6. Activar — depende de decisão separada e das etapas anteriores concluídas: registar arranque/rotas locais do módulo e abrir o percurso apenas para contextos/módulos adquiridos e utilizadores autorizados; reiniciar serviços persistentes pelo procedimento do host. Conferir o estado aplicado, acessos efectivos e a consulta do processo no destino, sem repetir as suites já aprovadas. Registar versão, schema, configuração, autoria e instante da activação. Só então reabrir escritas/workers. Não existe nesta entrega comando que concretize esta etapa; nenhum destes passos foi executado na instalação SGF.

Procedimento de recuperação por tipo de falha

Os ensaios aceites sustentam DDL transaccional e backup/restauro isolado; não equivalem a um instalador de recuperação automática de cliente. Não repetir os testes para esta classificação.

Situação	Acção exacta
Falha de preparação, antes de escrever no destino	Abandonar a preparação; conservar o código/ponteiro 0.1.1 e a base intactos. Não há migração ou reversão de dados a executar.
Excepção durante a transacção de schema	Fazer rollback da transacção; conferir ausência de tabelas/alterações parciais e igualdade com o inventário prévio. Se a ligação se perder durante o commit, primeiro inspeccionar schema e registo de revisão; não pressupor rollback nem repetir Schema::install às cegas. Manter o módulo desactivado até esclarecer o estado.
Código não arranca após schema confirmado, antes de novas operações	Retirar o novo registo de rotas/arranque e regressar ao código/configuração anterior arquivados; reiniciar os serviços. Manter o schema aditivo e os dados, incluindo auditoria. O ponteiro 0.1.1 não reverte alterações do host. Não executar down, truncar ir_*, estreitar a coluna de permissões ou remover direitos/histórico por arrasto.
Falha numa submissão/decisão ou resposta perdida	Conservar a identidade/contexto e repetir exactamente a mesma chave, versão e conteúdo; o recibo devolve o efeito já confirmado ou a transacção recomeça sem reserva duplicada. Se houver conflito de versão/conteúdo ou revogação, consultar o processo com identidade autorizada; não gerar uma nova origem para contornar o erro.
Corrupção/dados ou schema incompatíveis após operações novas	Suspender escritas/workers; preservar também uma cópia do estado que falhou e operações posteriores ao corte. Restaurar o backup numa nova base vazia, nunca por cima da base em uso. Conferir tabelas/dados, schema/constraints/triggers e consulta de origens/versões/reservas. Reconciliar explicitamente as operações posteriores ao backup e a configuração/autorização actual, incluindo revogações; um backup antigo não deve reabrir acessos revogados. Só apontar a aplicação à base recuperada após conferência e decisão registada. Conservar a base anterior para diagnóstico.

Forma dos comandos PostgreSQL usados na prova aceite, a adaptar ao destino conferido e à autenticação administrativa local, não executados nesta conferência:

pg_dump --format=custom --file=<arquivo-backup.dump> --dbname=<base-origem-conferida>
pg_restore --list <arquivo-backup.dump>
createdb --owner=<proprietario-autorizado> <nova-base-vazia-de-recuperacao>
pg_restore --no-owner --no-privileges --exit-on-error --dbname=<nova-base-vazia-de-recuperacao> <arquivo-backup.dump>

O restauro da prova usou uma role restrita proprietária da nova base. --no-owner --no-privileges não restaura roles/grants PostgreSQL: estes devem ser preservados no inventário administrativo e repostos explicitamente no ambiente de recuperação. As permissões funcionais da aplicação são dados da base e também exigem reconciliação temporal. pg_restore --list só lê o índice; a prova de recuperação aceite é o restauro efectivo com reconciliação das 22 tabelas e consulta posterior já registados. Os comandos não restauram documentos externos, .env, dependências ou código; estes têm cópias/procedimentos próprios. Não há comando único entregue para fazer a troca operacional da base.

Entrega distinta da reorganização modular do SGF

Esta entrega é a integração candidata de requisições internas. Extrair um motor e preparar um adaptador não comprova a reorganização modular do SGF pedida posteriormente. Essa reorganização continua pendente, sem resultado apresentado nesta entrega, e deve ter inventário, alterações e resultado próprios. Não a contar como concluída na matriz nem usar esta classificação como autorização para a executar por arrasto.

Dados/schema: ensaio separado da reversão de código

• Compras: migração aditiva 2026_11_01_000046_add_requisition_command_versions.php, sobre a base que já contém a migração 45. Acrescenta versão do processo e recibos imutáveis de comando; não reclassifica nem apaga dados. O caminho autónomo anterior continua utilizável sem instalar os recibos; o ecrã só envia chaves/versões quando o schema está preparado. down recusa apagar recibos já existentes. Nenhuma migração foi aplicada à base persistente de desenvolvimento.
• SGF: Schema.php acrescenta as tabelas ir_*, alarga o comprimento de permission_grants.permission e estende a condição de âmbito com os direitos privados da candidata. Conserva a condição anterior e os seus registos, sem conceder direitos. Políticas e histórico são versionados e imutáveis; snapshots submetidos e origem não são reescritos. A instalação foi ensaiada em PostgreSQL descartável já com identidades, concessões e orçamento sintéticos.
• Falha/compatibilidade: DDL transaccional com falha injectada preserva schema/dados anteriores e permite nova tentativa. Foi ensaiada uma evolução aditiva compatível com a candidata anterior. Isto não comprova compatibilidade com futuras alterações destrutivas.
• Recuperação: backup/restauro para outra base isolada, reconciliação de dados, colunas, constraints e triggers e consulta do processo restaurado. O backup de ensaio é sintético e não faz parte do pacote cliente. Uma recuperação real exige parar escritas e reconciliar operações posteriores ao backup; não há restauro automático sobre operações novas.
• Código: o updater continua limitado a código sem migrações. Voltar ao código 0.1.1 não remove tabelas nem restaura dados, e essa versão não apresenta o novo percurso. Não executar down nem recuperar uma base antiga como efeito implícito de rollback do ponteiro.

As provas e os resultados efectivos deste incremento constam de proofs/internal-requisitions-sgf.json. As provas históricas abaixo conservam o respectivo âmbito. Ecrãs foram verificados por HTTP, modelo de acções, tipos/lint e compilação; não houve revisão visual por navegador.

Verificação da candidata congelada	Resultado
Integração SGF pelo PHP 8.4.27 do host, PostgreSQL descartável	43 controlos; 2 origens, 2 requisições e 2 reservas, incluindo save/submit/decide concorrentes em processos separados
Adaptador autónomo e regressão de compras/orçamento em PostgreSQL descartável	46 testes / 339 asserções
Regressão completa de Compras em SQLite isolado	883 testes: 881 aprovados, 2 ignorados; 8.950 asserções; resultado final em proofs/internal-requisitions-validation.json
Recuperação de dados/schema	22 tabelas reconciliadas; constraints/triggers/colunas conferidos; consulta restaurada preserva origem e versão 3
Modelo dos ecrãs congelados, limites monetários exactos, envelopes de retry e headers	23 controlos Node; sem navegador
PHPStan dirigido, TypeScript, lint/formatação e build frontend	Aprovados; sem erros PHPStan ou avisos lint nos ficheiros verificados
Activação e permissões no SGF de destino	Ponteiro 0.1.1 preservado; candidata recusada pelo updater normal; nenhuma concessão aplicada

Percurso de actualização

Separação entre preparação e instalação cliente

Etapa	Acesso necessário	Dependência de Compras na instalação cliente
Produzir ZIP validado (publish-purchasing.php)	Fonte Compras e canal de saída; não precisa de pasta SGF	Nenhuma depois de produzido o artefacto
Coordenar prova/instalação no SGF de desenvolvimento (transfer-purchasing.php)	Pastas locais de Compras/SGF, wrapper e canal	É uma ferramenta de desenvolvimento, não o instalador obrigatório do cliente
Conferir/instalar no cliente (purchasing-release.php)	SGF do próprio cliente com dependências e ferramentas de arranque, ZIP e SHA-256 aprovado	Não usa pasta, base, sessão ou serviço de Compras
Executar a capacidade instalada	Loader, versão seleccionada e dependências locais do SGF	Não consulta a origem nem sincroniza dados com ela

Conferido por dois meios: teste em pasta cliente sintética com a pasta de origem renomeada para indisponível; e execução no SGF 0.1.1 verificando que todos os ficheiros PHP carregados pertencem ao próprio host. A segunda prova não arranca a aplicação nem liga à base. Isto comprova a independência do pacote actual, não a preparação completa de todos os futuros módulos de cliente.

No desenvolvimento, a partir de Compras:

composer purchasing:transfer -- C:/laragon/www/sgf-tempo C:/laragon/data/sgc-releases/purchasing

O comando usa o wrapper e o PHP fixado pelo SGF, sem substituir versões. Executa regressões da capacidade e do mecanismo; verifica que a origem não mudou durante os testes; prova uma fotografia imutável; publica essa mesma fotografia; compara com a versão instalada; prova a candidata com o PHP/dependências do SGF; instala se for mais recente. Sem alterações no pacote, não gera versão nem reinstala código. O exemplo de caminho é do ambiente local, não dependência do runtime ou do formato distribuído.

Para apenas produzir uma versão validada, usar composer purchasing:publish -- <canal>. O comando scripts/purchasing-release.php publish é a primitiva técnica sem execução de testes; a publicação normal usa o percurso validado anterior.

O canal contém catalog.json e ZIPs imutáveis. Há numeração patch automática por alteração dos bytes; source_sha256 identifica o conjunto exacto de ficheiros. O manifesto individual contém SHA-256 por ficheiro e contrato/capacidades do módulo. A validação rejeita ficheiros extra, ausentes, alterados, caminhos inválidos, entradas duplicadas e arquivos excessivos.

Na instalação cliente, distribuir o ZIP, os artefactos de arranque e a referência SHA-256 por canal de confiança. Não é necessário o checkout de Compras:

php scripts/purchasing-release.php check <raiz-SGF> <versao.zip> <sha256-manifesto>
php scripts/purchasing-release.php install <raiz-SGF> <versao.zip> <sha256-manifesto>
php scripts/purchasing-release.php status <raiz-SGF>
php scripts/purchasing-release.php rollback <raiz-SGF>

O SHA-256 confere integridade contra a referência aprovada; não autentica sozinho um canal remoto. Não há download ou activação a partir de URLs arbitrários. Um catálogo remoto assinado e verificação de assinatura ainda não integram esta entrega.

Preservação e recuperação

Cada versão ocupa packages/purchasing/releases/<versão>; current.json é o ponteiro local. A instalação valida a versão actual antes de actualizar, prepara a candidata separadamente, regista histórico e troca o ponteiro atomicamente sob lock. Não apaga a versão anterior. Uma alteração local ao código instalado bloqueia a actualização em vez de a sobrescrever. Versão igual com conteúdo diferente e downgrade implícito são recusados. A reversão explícita confere os bytes anteriores e não recalcula nem apaga dados.

current.json, locks e histórico são estado da instalação e não credenciais/contas distribuídas. O SGF pode arrancar sem este módulo opcional instalado; depois da instalação, o provider carrega o pacote verificado. O histórico é local e não deve ser transplantado de uma empresa para outra.

O formato actual recusa pacotes com alterações de schema ou concessões. Os comandos de instalação/prova do primeiro incremento não abriram bases nem executaram migrações, seeds, alterações de contas, permissões, stock, finanças ou contratos. A nova candidata de requisições ensaiou persistência apenas em bases sintéticas descartáveis, conforme secção própria, sem alargar o contrato do updater. Serviços persistentes devem ser reiniciados pelo procedimento operacional depois de actualizar; o instalador não termina processos.

Alcance exacto da reversão

Elemento	Cobertura actual
Código do pacote e versão seleccionada	Reversão explícita para a versão anterior, depois de conferir integridade; histórico local e troca de ponteiro
Dependências PHP/Composer e frontend do host	Não são substituídas nem revertidas por este mecanismo
Dados empresariais, schema, configuração e permissões	Não são alterados nem revertidos pelo actual contrato
Migrações de dados/schema	Fora do updater; na candidata interna, DDL falhada, compatibilidade aditiva e backup/restauro em base isolada ensaiados separadamente; sem down/restauro automático

O manifesto exige database_changes=false e o formato não aceita pastas de migração/seed; isso delimita o contrato distribuído actual, não torna PHP futuro uma sandbox. Uma capacidade com persistência exige antes um contrato de migração com autoria/versão, schema compatível, aplicação idempotente, auditoria, destino conferido e backup/restauro ensaiados em isolamento. Deve distinguir reversão de código compatível, correcção por migração seguinte e eventual restauro de dados com plano de reconciliação. Não executar automaticamente down, apagar históricos ou restaurar um backup antigo sobre novas operações. A estratégia concreta terá de acompanhar o percurso escolhido.

Provas e limites

Conferência adicional antes de ampliar: seis testes do mecanismo/29 asserções, incluindo execução em cliente com origem indisponível; prova SGF em PHP 8.4.27, versão activa 0.1.1, todos os ficheiros carregados no próprio host e nenhuma ligação à base. Ver proofs/purchasing-client-independence.json. As provas do primeiro incremento abaixo mantêm o seu âmbito histórico. A candidata 0.1.2 contém preparação económica, mas não foi instalada; não contar os testes dessa preparação como prova do processo económico no SGF.

• Compras: 86 testes/566 asserções no percurso de publicação (reposição, histórico, lotes, coordenação, sugestões, estornos, contagens e cinco testes do mecanismo).
• SGF: dois testes/11 asserções, executados com o wrapper e PHP 8.4.27, sem base; execução real do pacote e resultados de consumo manual, média racional e lotes.
• Publicação 0.1.0 e actualização 0.1.1 instaladas localmente. A segunda versão acrescenta documentação do contrato de distribuição; o algoritmo transferido permaneceu igual.
• Reversão real 0.1.1 → 0.1.0 e reactivação 0.1.1 conferidas, sem dados/permissões alterados.
• Cinco testes do instalador cobrem publicação sem duplicação, nova versão, retry, rollback/reactivação, código local alterado, manifesto errado, conteúdo adulterado, path traversal, ficheiro ausente, segredo na origem e pedido de alteração de schema.
• Fachada e motor comum passaram análise PHP dirigida. Fonte do mecanismo e artefactos SGF conferidos em packages/module-updates/runtime-manifest.json.

Limitação central: este mecanismo actualiza as capacidades já extraídas para o pacote; não transfere automaticamente melhorias ainda confinadas aos controladores/serviços/ecrãs de Compras. Continuar a migração pela matriz acima, sem declarar todo o SGF actualizado só porque a versão do pacote mudou. Não há publicação no domínio ou conclusão de integração de RH nesta entrega.

Candidata utilizável de requisições — 02/11/2026

Esta secção actualiza a matriz para a candidata OPERATIONAL-CANDIDATE-401ce31ae5f2dd20, schema revisão 2, e substitui apenas as lacunas administrativas/orçamentais identificadas na proposta anterior. A distribuição instalada mantém 0.1.1; não houve instalação/activação/publicação.

Capacidade	Candidata / prova	Destino
Dependências da interface orçamental	cb_ui_commands e cb_consumption_sources incluídas, estruturas existentes reutilizadas; 16 tabelas novas no total	Não migrado
Administração de direitos	Acessos React usa catálogo/rótulos do servidor, filtro por direito próprio e unidade; servidor valida delegação/revogação	Sem concessões
Centros e dotações	Formulário de centro, preparação pela API comum, aprovação independente; sem fixtures necessárias	Sem dados novos
Requisição básica	Consumível/serviço/outro → submissão e reserva única → aprovação distinta → consulta/histórico	Não activado
Equipamentos/peças	Rejeitados; fora do incremento	Não activado
Privilégios mínimos	Roles separadas, CREATE/ALTER negados ao runtime; mapa restringe ACLs herdadas só em objectos novos	Apenas proposta; não aplicada
Recuperação	Sucessor de código + rollback sem alterações de dados; dump restaurado e 103 tabelas reconciliadas, schema/decisão/reserva preservados	Sem restauro/mudança
Navegação	Código funcional 2a4169162b preservado; Início/Opções gerais separados	19 hashes inalterados

Provas afectadas: 157 controlos integrados + 17 React/render/assets + 54 aplicação/interrupção/recuperação de código. Não são testes de carga ou revisão visual. As suites anteriores válidas são reutilizadas; as 87 comparações de ACL integram os 157 controlos. Bases/roles sintéticas removidas. Ver prova consolidada e proposta única revista, com hashes/recuperação de código, schema e dados separados.

Pendências mantidas: revisão visual sem nova tentativa pela via bloqueada; associações antigas sem atribuição automática; volume/paginação; decisão posterior de instalação, mapa SQL e configuração/autoridades do destino. A candidata não inclui pagamentos/recepções/ordens/stock ou direitos reais por arrasto.

Revisão da proposta para desenvolvimento sintético — 02/11/2026

A proposta SGF-IR-USABLE-401C-20261102 foi completada, sem execução: destino novo em C:/laragon/data/sgf-tempo/run/ir-usable-401c-20261102/app, HTTP8041, cluster55441/base sgf_ir_dev_401c_20261102, owner/runtime novos separados. Origem exclusivamente sintética 8039 preservada; as nove baselines são compatíveis. Fonte contém 93 tabelas (incluindo seis wc_* fora deste incremento), portanto migração nova será 93→109, não 87→103. Perfis #1/#2/#3 reutilizados somente na cópia; três contas sintéticas novas de administração/Compras/Financeiro propostas. Dotação fictícia 50 000 MZN/2026, limites 10 000/20 000, concessões exactas na proposta. Mapa SQL mínimo dirigido à role nova, não sgf_dev_app. Nenhum provisionamento, concessão, migração ou activação executados. Provas antigas reutilizadas sem declarar o destino novo testado. Ver PURCHASING_INSTALLATION_PROPOSAL.md e proofs/sgf-ir-synthetic-installation-proposal.json. A versão anterior da proposta ficou arquivada e não deve ser executada.

Execução autorizada em 8039 — 02/11/2026

Concluída/conferida exclusivamente na demonstração existente 8039/base sgf_modules_dev_2576427d1939/55439/contexto1:1:1: 14 direitos (8/4/2), centro SINTETICO-REPRO/OPER, dotação 10 000 MZN/2026 por #1 aprovada por #2 e requisição de 100 MZN com reserva única e aprovação independente. Direitos/contas anteriores preservados, sem GRANT/REVOKE SQL ou novas contas. A proposta8041 permanece adiada. Ver SGF_REQUISITIONS_8039_DELIVERY.md e provas associadas. Consulta #3 tem listagem acessível mas 404 no registo de outro autor pela visibilidade existente; nenhuma ampliação de direitos/código foi feita. Backup anterior conferido; restauro efectivo deste backup não é declarado nesta passagem. SGF real/Tempo e 0.1.1 preservados; revisão visual/associações antigas/volume-paginação separados.