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](WORKSHOP_MANAGEMENT_SCOPE.md#13-primeiro-recorte-coordenado--ordem-e-recursos) 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](proofs/workshop-browser.png), [resumo visual](proofs/workshop-browser-summary.png), [resultados conferidos](proofs/workshop-browser-results.json) e [concorrência](proofs/workshop-concurrency.json).

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](proofs/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
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](WORKSHOP_RESOURCE_ACCEPTANCE.md). 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.