SGF/docs/WORKSHOP_RESOURCE_DELIVERY.md

Oficina — entrega técnica isolada de ordem e recursos

27/10/2026, Africa/Johannesburg. WORKSHOP-RESOURCE-RECORD-v1, conforme âmbito, secção 13 e precisão posterior sobre ocorrências já acontecidas. Entrega técnica para revisão; não significa aceitação do utilizador. Preservados 4276aca, alterações posteriores e recebimentos, cuja aceitação continua separada. Sem novo checkpoint.

Funcional

• Abertura de ordem com cliente existente e um equipamento individual, localização, pedido, evidência e referência operacional única. Equipamento pode ser reutilizado por ID, sem repetir cadastro por ordem.
• Atribuição explícita de técnico com pertença e direitos próprios. Abertura, atribuição e autorização são comandos separados: abrir não autoriza executar. Nenhuma supervisão técnica foi atribuída à Samira.
• Tarefas versionadas com origem estável. Serviço existente pode ser referenciado quando compatível; não criar serviço fictício, material/stock ou ordem de produção.
• Autorização ligada à versão exacta da tarefa: pessoa que autorizou, qualidade/representação, data, canal, alcance e comprovativo/contrato, separada do operador que registou. Não se declara que a referência comprova assinatura digital ou validade externa.
• Início de trabalho exige autorização já registada e compatível. Outra tarefa/versão exige revisão explícita. Autorizações e âmbitos anteriores não são reescritos.
• Relato retrospectivo de tempo/material é permitido mesmo sem autorização. O servidor/base marca consumo/execução fora do âmbito; não transforma o relato em autorização ou confirmação automática. Autorização posterior não altera o registo histórico. Uma correcção de ocorrência já sinalizada conserva a excepção.
• Verificação/recusa referem a versão exacta, por identidade distinta do autor. Ocorrência fora do âmbito não pode receber verified; admite acknowledged (facto reconhecido apenas para auditoria) ou refused. Reconhecimento não acrescenta tempo/aplicação verificados nem remove a marca de excepção.
• Tempos com início/fim, zona, pausas, trabalho/deslocação e minutos efectivos exactos. Pausas inválidas, duração negativa/futura/subminuto não representável e sobreposição do mesmo técnico são recusadas. Técnicos diferentes podem ter intervalos simultâneos.
• Materiais com identidade de recurso, unidade, propriedade empresa/cliente, origem, quantidade e ocorrência distinta: requerido, entregue, aplicado/consumido, devolvido. Reserva não é uma opção suportada. Requisição/entrega/devolução não constituem por si autorização de execução ou consumo.
• Consulta da ficha, versões, decisões, totais relatados versus verificados e diferenças físicas a explicar. Sem custos, preços, margem, facturação, recibo ou lançamento.

Origem, versões e integridade

Cada apontamento conserva ID, ordem, tipo, origem, versão, predecessor, tarefa/autorização/início quando aplicáveis, técnico, quantidades/unidade ou tempos, datas, autor e evidência. A identidade de origem por ordem/tipo é estável; novas versões são explícitas e não eliminam originais. A verificação antiga permanece associada à versão antiga e não verifica a nova.

Futuro custeio pode referenciar ID/versão de origem, sem criar outra ocorrência de consumo ou hora. Não foi implementado o consumidor industrial nem um repositório universal de recursos. Os eventos de oficina têm schema/causação próprios e não são reclassificados como produção ou acontecimentos financeiros.

Comando, ordem/apontamento/decisão, auditoria, evento e outbox são transaccionais. Repetição da mesma chave e conteúdo recupera IDs; conteúdo diferente entra em conflito. Uma chave nova não contorna a unicidade de referência/origem. Há testes de rollback de abertura (incluindo equipamento) e de apontamento quando falha o outbox, e replay após resposta perdida.

SQL: FKs e triggers validam empresa/cliente/equipamento, versão/ordem/tarefa/autorização, atribuição, minutos/pausas, sobreposição, propriedade/unidade de material, autor e decisão. Todas as sete tabelas são append-only, também contra UPDATE/DELETE em massa. Escritores são serializados por linha da empresa; a consulta usa a mesma ordem de bloqueio para uma versão coerente. Não se apresenta este mecanismo como RLS ou capacidade de escala de produção. SQL administrativo continua uma fronteira de confiança distinta da identidade autenticada na aplicação.

Sessão, CSRF, pertenças, unidade, direito específico e atribuição são revalidados no servidor e dentro do comando. Técnicos vêem apenas ordens actualmente atribuídas; abertura/verificação têm consulta delimitada à unidade autorizada. Listas de clientes são limitadas às ordens visíveis salvo função de abertura; lista de técnicos apenas para quem atribui. Revogar acesso tem efeito no pedido seguinte, inclusive em replay.

Bloqueio operacional

WorkshopWorkflow::guard() exige testing/browser-testing e TestingDatabaseGuard confirma sgf_tempo_test, cluster próprio 127.0.0.1:55432, utilizador de testes e ligação efectiva. A consulta normal apresenta bloqueio/listas vazias para quem tiver direito, sem depender de as tabelas novas existirem. Não há flag para activar utilização real.

Os INSERT nas tabelas wo_* têm também guarda SQL de base sgf_tempo_test e porta 55432. Não se criaram ordens, equipamentos, contas ou concessões reais. ServiceInvoicing::guard(), cálculo fiscal, B1 e recebimentos não foram alterados. Sem acesso ao InvesteMoz, alterações globais ou dependências novas.

Demonstração no navegador e provas

Edge, http://127.0.0.1:8001, sessão/cache isolados e CSRF activo. Login real com três identidades artificiais distintas; não se usou actingAs como prova de login. Credenciais aleatórias ficam no ficheiro local protegido do preparador, nunca neste relatório.

1. Abertura: gestor sintético entrou em Empresa Horizonte — Demonstração / Unidade Central — Demonstração / Oficina de teste. Abriu OT-BROWSER-ABERTA com cliente/equipamento/pedido/evidência, sem autorização implícita.
2. Origem do caso principal: a fixture preparou OT-TEST-PRINCIPAL, atribuição, tarefa e autorização pelos comandos de negócio. Usou relógio artificial apenas no processo CLI, no dia anterior às 08:00; restaurou-o no fim. Não alterou relógio do sistema, servidor normal ou política fiscal. Não pré-criou tempos/materiais.
3. Técnico: login separado, só ordem atribuída visível; relato de 09:00–11:00 no dia da fixture, pausa 10:00–10:15 → 105 MIN. Depois registou material CABO-TEST: 3 UN entregues, 2 aplicadas e 1 devolvida, com três origens distintas. Não foram movimentos de stock.
4. Âmbito: acrescentou tarefa ainda não autorizada. Iniciar trabalho autorizado foi recusado. Apesar disso, conseguiu relatar uma ocorrência material passada para essa tarefa; ficou FORA DO ÂMBITO AUTORIZADO, com origem e diferença física pendente.
5. Verificador: terceiro login, sem registo técnico/abertura. Verificou tarefa, tempo e materiais principais. Totais: 105 MIN verificados, aplicação verificada 2 UN. Reconheceu a ocorrência fora do âmbito apenas para auditoria; aplicação verificada dessa ocorrência continua zero.
6. Autorização posterior: gestor registou uma autorização específica adicional. A ocorrência das 11:00 continuou fora do âmbito e a decisão de auditoria não mudou; nada ganhou cobertura retroactiva.
7. Recusa: técnico registou TEST-REVIEW-REFUSAL; verificador recusou com fundamento «Descrição insuficiente; corrigir o apontamento antes de o verificar». Original e decisão preservados. Correcções, versões antigas e recuperação são cobertas também por testes e processos concorrentes.

Prova completa no navegador, resumo visual, resultados conferidos e concorrência.

O caso adicional sem entrega documentada mostra diferença observada de −1 UN e pendência, não saldo negativo de armazém ou material automaticamente disponibilizado. Somas são dos apontamentos registados; ausência de ocorrência de entrega não prova que a quantidade física real foi zero. A verificação reconhece evidência de teste, não certificação externa.

Testes, concorrência e compilação

Resultados finais em workshop-tests.json. Filtro relevante: WorkshopTest|ServiceReceivablesTest|InternalConfirmationTest|DatabaseSafetyTest. A regressão inclui recebimentos, preservando a sua aceitação separada; não repete toda a investigação fiscal ou suites sem relação.

Resultado final: 41 testes, 832 asserções, zero falhas/erros. Oficinas isoladamente: 11 testes, 243 asserções. Compilação aprovada com Vite 8.3.5, sem novas dependências.

Numa execução anterior da regressão houve uma recusa de hash de revisão desactualizada na preparação de factura sintética de ReceivablesFixture, antes do cenário de recebimentos. A repetição com o mesmo código passou integralmente; a causa da intermitência não foi demonstrada. Regista-se esta limitação sem afrouxar a guarda de revisão ou alterar o núcleo fiscal.

Cobertura: início sem autorização, relato retrospectivo auditável, autorização posterior e alteração de tarefa/versão, auto-verificação, recusa e nova versão, imutabilidade SQL, valores/unidades/pausas inválidos, sobreposição individual e simultaneidade de técnicos distintos, contexto antigo, empresa irmã/unidade não autorizada, revogação, destino de teste incorrecto, ambiente normal/CLI, idempotência, falhas de outbox e recuperação sem duplicação.

Seis provas com dois processos realmente sobrepostos:

• Mesma abertura → uma ordem e um replay.
• Mesmo apontamento → uma inserção e um replay.
• Tempos incompatíveis do mesmo técnico → um aceite e um conflito.
• Mesma verificação → uma decisão e um replay.
• Nova versão versus decisão sobre a antiga → uma revisão vencedora e recusa da decisão antiga.
• INSERT SQL em ordens diferentes, com o mesmo técnico/intervalo → guarda de sobreposição recusa o segundo, sem depender apenas da revisão da mesma ordem.

A prova SQL insere dados deliberadamente por via administrativa para testar invariantes; não representa comandos de aplicação auditados. Todos os casos são sintéticos. A instância do navegador é parada antes dos testes finais, que recriam só a base de testes; imagens/resultados preservam a prova e os IDs não são fixos numa repetição.

Repetição local isolada

powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 test '--filter=WorkshopTest|ServiceReceivablesTest|InternalConfirmationTest|DatabaseSafetyTest'
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 npm run build
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/browser-proof.ps1 start
powershell -NoProfile -ExecutionPolicy Bypass -File scripts/sgf.ps1 php scripts/workshop-fixture.php --env=testing

No navegador seleccionar o contexto acima e Oficina de teste. Usar os utilizadores sintéticos gestor@example.test, tecnico-oficina@example.test e verificador-oficina@example.test, com credencial gerada no preparador protegido. Não usar contas reais ou revelar credenciais. A data da fixture está no manifesto local; preencher o intervalo do dia anterior como indicado na prova.

Para concorrência, executar sgf.ps1 php scripts/workshop-concurrency.php --env=testing. Para conferir os resultados depois de repetir o percurso descrito, sgf.ps1 php scripts/workshop-proof.php --env=testing. Os preparadores recusam estado já preenchido e não apagam dados para prosseguir. Terminar a instância com powershell -NoProfile -ExecutionPolicy Bypass -File scripts/browser-proof.ps1 stop antes de testes destrutivos. Portas ocupadas não autorizam parar processos alheios.

Migração em desenvolvimento — delta proposto, NÃO aplicado

2026_10_27_080000_create_workshop_resource_records.php, SQL em database/sql/workshop.sql, confirmado Pending por leitura de migrate:status em sgf_tempo_dev.

Cria sete tabelas: wo_equipment (identidade individual), wo_orders (abertura), wo_entries (atribuições/tarefas/autorizações/inícios/tempos/materiais versionados), wo_decisions (verificações), wo_commands (idempotência), wo_events e wo_outbox. Acrescenta FKs, índices e funções/triggers próprios de integridade, ambiente e imutabilidade. Amplia o CHECK de permissões com seis nomes workshop.* exclusivamente de unidade, preservando alternativas existentes. Não atribui direitos ou altera tabelas operacionais anteriores. Não há down() destrutivo.

Só aplicar em sgf_tempo_dev após confirmação específica, com proprietário separado e comparação de integridade antes/depois; sem reset/fresh. Mesmo instalada, a guarda SQL e de aplicação continua a impedir uso operacional nessa base.

Atenção ao âmbito do comando futuro: 070000 de recebimentos também está pendente e não foi autorizada nesta tarefa. Não executar uma migração geral que aplique ambas por arrasto. Uma eventual autorização apenas de oficina exige execução dirigida ao ficheiro 080000, com o proprietário de migração e destino conferidos. Esta entrega não modificou o wrapper ou executou esse comando.

Permissões propostas — separadas, nenhuma concedida

Pré-visualização read-only disponível em scripts/workshop-permissions-preview.php, sem modo de aplicação. Conferência em 27/10/2026: conta #1 Osmane Nala, nala@tempo.co.mz; tenant #1, Tempo Lda #1, SEGI #1. Nenhum dos quatro direitos abaixo estava atribuído.

Função / titular	Proposta, sempre na unidade autorizada	Aplicação real
Abertura — Osmane #1, Tempo Lda #1 / SEGI #1	workshop.view, workshop.open, workshop.assign, workshop.authorize	Quatro concessões propostas; confirmação específica antes de aplicar
Técnico responsável	workshop.view, workshop.record, condicionados à atribuição actual	Conta real ainda não identificada; nenhuma conta criada ou proposta nominal inventada
Verificador distinto do autor	workshop.view, workshop.verify	Conta real ainda não identificada; não atribuir à Samira por consequência das suas funções actuais

Não incluem gestão de acessos, custos/margens, stock, fiscalidade ou emissão. Técnicos/verificadores sintéticos foram criados só na base de testes com esta matriz explícita. Conceder os direitos no futuro não retira o bloqueio operacional; activação real exige outro âmbito específico.

Aceitação posterior

Entrega isolada aceite expressamente pelo utilizador em 27/10/2026. Ver registo de aceitação e limites do checkpoint. A aceitação não aplica migrações ou concessões, não activa uso operacional e não abrange a aceitação de recebimentos. A referência anterior a ausência de aceitação presumida descreve correctamente a entrega antes desta confirmação.

Aplicação específica posterior em desenvolvimento — 27/10/2026

Após autorização específica do utilizador, foi aplicada apenas 2026_10_27_080000_create_workshop_resource_records em sgf_tempo_dev, por caminho explícito, com sgf_dev_owner separado da aplicação. O registo de migrações acrescentou exactamente essa entrada; 070000 permanece pendente. As indicações anteriores de migração/concessões pendentes descrevem o estado anterior a esta autorização.

Foram concedidos exactamente quatro direitos à conta existente Osmane #1, tenant #1 / Tempo Lda #1 / SEGI #1: workshop.view, workshop.open, workshop.assign, workshop.authorize. Cada concessão foi auditada. Não se criaram contas ou direitos para técnico/verificador, nem direitos de registo/verificação ou gestão de acessos.

O procedimento scripts/workshop-dev-install.php comparou em memória as impressões dos registos preexistentes antes/depois, incluindo acessos e auditoria anteriores. Só se acrescentaram o registo da migração, quatro concessões e quatro eventos de auditoria. As sete tabelas novas estão vazias. O resumo local fica em storage/app/private/workshop-dev-install-proof.json, excluído do Git; não exporta conteúdos dos registos ou credenciais.

Verificação no papel normal sgf_dev_app: listagem bloqueada e vazia; guarda, abertura, registo e verificação recusados com 403; sgf_wo_environment() recusou a base de desenvolvimento; emissão real continua recusada. Não se inseriram ordens ou apontamentos de demonstração em desenvolvimento. Não foram alterados código funcional, ferramentas ou dependências, pelo que não se repetiu a demonstração aceite ou a compilação. O procedimento de instalação é deliberadamente não repetível sem revisão do estado.

O checkpoint aceite 21a91f2 mantém-se preservado. Esta aplicação não aceita recebimentos, não activa utilização operacional, não implementa custos industriais e não autoriza publicação.

Ficheiros e limites

Principais alterações: app/Modules/Workshop/WorkshopWorkflow.php, Http/WorkshopController.php, resources/js/WorkshopWorkspace.jsx, integração em resources/js/app.jsx e routes/web.php; migração/SQL acima; tests/Support/WorkshopFixture.php, tests/Feature/WorkshopTest.php; scripts workshop-fixture.php, workshop-worker.php, workshop-concurrency.php, workshop-proof.php e workshop-permissions-preview.php; documentação/provas desta entrega.

Limites: um cliente/equipamento por ordem, tarefas simples e autorização por versão de tarefa; tempos completos em minutos, sem apontamentos subminuto ou timer geral; UI recebe uma pausa, API várias; conservadoramente, todo o intervalo individual está ocupado, mesmo durante pausa. Outro técnico pode trabalhar em simultâneo. Correcções de tarefa/tempo/material pelo próprio autor actualmente atribuído; não há edição histórica por supervisor ou transferência silenciosa de autoria. Interface inicial abre equipamento novo; reutilização por ID suportada na API, sem editor completo de cadastro.

Não há stock, disponibilidade, valorização, custos industriais, tarifas, horas facturáveis, orçamento/contrato automatizado, aceite/entrega completos, assinatura digital, conversão comercial, factura, recebimento, receita, lançamento ou fecho. Dados/evidências são declarados pelo operador; a aplicação não comprova externamente a representação do cliente ou a autenticidade do documento. Pendências reais e conformidade permanecem como estavam. Não houve publicação ou aceitação presumida.