213 lines
6.9 KiB
Markdown
213 lines
6.9 KiB
Markdown
# Tarefas — em ordem de execução
|
||
|
||
> Cada tarefa tem **critério de aceite**: o que precisa acontecer para ela ser
|
||
> considerada pronta. Sem isso, "terminei" vira discussão.
|
||
>
|
||
> A ordem importa: as três primeiras não dependem de decisão de ninguém.
|
||
|
||
---
|
||
|
||
## Bloco A · Pode começar hoje
|
||
|
||
Nada aqui depende de resposta pendente.
|
||
|
||
### A1 · Limpar os marcadores do Tiny
|
||
**Aceite:** a lista de sugestão de marcadores só mostra os padrões. Os pedidos
|
||
antigos mantêm o histórico intacto.
|
||
|
||
- Criar `DTF-PRODUCAO`, `DTF-PRONTO`, `DTF-PROVA-COR`
|
||
- Remover da lista de sugestão: `inicio 14:45`, `inicio13:34`, `1hrs`, `3h`,
|
||
`+30min de correcao` e as demais variações digitadas à mão
|
||
- **Não apagar do histórico dos pedidos** — só da lista de opções
|
||
- **Preservar** `30 min`, `1 hora`, `3 horas`: são estimativa de máquina
|
||
|
||
### A2 · Contratar a infraestrutura
|
||
**Aceite:** `https://arte.dropstaratacado.com.br` responde com certificado
|
||
válido, e um arquivo de teste sobe e desce do storage.
|
||
|
||
- VPS Linux 2 vCPU / 4 GB · Hetzner, Contabo ou Hostinger
|
||
- Storage S3 compatível · Cloudflare R2 ou Backblaze B2
|
||
- Subdomínio + Let's Encrypt
|
||
- Bucket `dtf-artes` com ciclo de vida de 30 dias
|
||
- Prefixo `artes-cliente/` com 12 meses
|
||
- CORS liberado só para o domínio do portal
|
||
|
||
### A3 · Criar o banco
|
||
**Aceite:** `schema.sql` roda sem erro no Postgres e no SQLite.
|
||
|
||
- Postgres na nuvem · SQLite na fábrica
|
||
- Dump diário do Postgres para o storage
|
||
|
||
### A4 · Provisionar acessos
|
||
**Aceite:** um token do Tiny obtido por código, e um WhatsApp de teste enviado.
|
||
|
||
- Aplicação na API v3 do Tiny · client id e secret
|
||
- **Confirmar na documentação** o endpoint de marcadores e o limite de req/min
|
||
- WhatsApp: definir Meta oficial ou provedor
|
||
|
||
---
|
||
|
||
## Bloco B · Portal — entrega sozinho
|
||
|
||
Ao fim deste bloco a Altus **já recebe arte 24 horas**, mesmo sem kanban.
|
||
|
||
### B1 · Webhook e link
|
||
**Aceite:** um pedido criado no Tiny gera link e chega no WhatsApp em menos de
|
||
1 minuto.
|
||
|
||
- `POST /webhook/tiny` → cria pedido, token de 7 dias, dispara WhatsApp
|
||
- Idempotente: pedido repetido não duplica
|
||
- **Medir a latência VNDA → Tiny** e registrar
|
||
|
||
### B2 · Página de upload
|
||
**Aceite:** um arquivo de 5 GB sobe sem derrubar o VPS.
|
||
|
||
- URL pré-assinada, upload em partes
|
||
- Campo de repetição com prévia da conta
|
||
- Gabarito 57 × 97 cm para download
|
||
- Rate limit de 20 req/min por token
|
||
|
||
### B3 · Pré-flight
|
||
**Aceite:** dos cinco arquivos que os designers separarem, o robô decide igual
|
||
ao que eles decidiriam.
|
||
|
||
- `preflight.py` está pronto — integrar e testar
|
||
- Normalização: vetor → PDF, raster → TIF, CMYK → RGB, **original preservado**
|
||
- Repetição, fatiamento em 20 m, carimbo com QR de 20 mm
|
||
- CDR entra sem validar, etiqueta "conferir"
|
||
- **`carimbar()` precisa de teste visual impresso** antes de valer
|
||
|
||
### B4 · Mensagens
|
||
**Aceite:** as seis mensagens chegam com o texto certo, e a de correção pede
|
||
resposta.
|
||
|
||
- Lembrete de 1 hora sem arte
|
||
- Recusa com motivo em português
|
||
- Aprovação com **% e DPI**, metragem, tempo e horário previsto
|
||
- Em produção, correção, finalizado
|
||
|
||
### B5 · Antivírus
|
||
**Aceite:** um EICAR de teste é barrado e não chega ao agente.
|
||
|
||
- ClamAV em segundo plano, sem travar a fila
|
||
|
||
---
|
||
|
||
## Bloco C · Agente
|
||
|
||
### C1 · Serviço na fábrica
|
||
**Aceite:** derrubar a internet por 10 minutos e religar — o agente baixa o
|
||
acumulado sozinho, sem duplicar nada.
|
||
|
||
- Windows via NSSM ou Linux via systemd
|
||
- Webhook + polling de 60 s
|
||
- Download em arquivo temporário, renomeia só quando completa
|
||
- Verificação de SHA-256
|
||
- Idempotente pelo `arte_id`
|
||
|
||
### C2 · Monitoramento
|
||
**Aceite:** matar o processo dispara alerta em até 15 minutos.
|
||
|
||
- Heartbeat a cada 5 min
|
||
- Alerta ao TI se sumir
|
||
|
||
---
|
||
|
||
## Bloco D · Kanban como aba do PCP
|
||
|
||
### D1 · Quadro
|
||
**Aceite:** dois operadores clicando `puxar` ao mesmo tempo — só um pega.
|
||
|
||
- 7 colunas · **sem coluna de aplicação**
|
||
- Cronômetro por card, em tempo real
|
||
- Front pronto em `kanban/static/kanban.html`
|
||
- `?maq=4` abre filtrado na máquina
|
||
|
||
### D2 · Puxar e devolver
|
||
**Aceite:** puxar e não mover em 3 minutos devolve o pedido à fila sozinho.
|
||
|
||
- Reserva de **3 min** · **um pedido por vez**
|
||
- Devolver volta ao **topo**
|
||
- Círculo vermelho na máquina ocupada, botão desabilitado
|
||
|
||
### D3 · Movimento e integração
|
||
**Aceite:** desligar o Tiny, mover cards, religar — os marcadores entram sozinhos
|
||
e nenhum movimento se perde.
|
||
|
||
- Gravar o movimento **antes** de qualquer chamada externa
|
||
- Fila de jobs com retentativa em 1, 5 e 30 min
|
||
- Três marcadores no Tiny, não sete
|
||
- Arquivo acompanha o card entre as pastas
|
||
|
||
### D4 · Estimativa de máquina
|
||
**Aceite:** o card sugere os minutos e aceita ajuste manual.
|
||
|
||
- Campo `minutos_maquina`, sugerido por `metros/20*60`
|
||
- Importar os marcadores `30 min`, `1 hora`, `3 horas` dos pedidos existentes
|
||
|
||
### D5 · Retrabalho
|
||
**Aceite:** a causa não pode ser alterada depois de aberta, nem pelo autorizador.
|
||
|
||
- Abertura com causa obrigatória e evidência
|
||
- Alçada automática · reincidência sobe nível
|
||
- Contestação registrada sem alterar a causa
|
||
- **Meta ainda não definida** — `META_POR_CAUSA` isolado
|
||
|
||
### D6 · Painel e relatórios
|
||
**Aceite:** os quatro relatórios respondem com dados reais depois de uma semana.
|
||
|
||
- Filtros de período
|
||
- `/api/relatorio/etapas`, `/impressao`, `/aproveitamento`, `/retrabalho`
|
||
- Aproveitamento lendo as transferências do depósito no Tiny
|
||
|
||
---
|
||
|
||
## Bloco E · Só depois de medir
|
||
|
||
**Duas semanas com o kanban rodando antes de tocar nisto.**
|
||
|
||
### E1 · Decidir o terceiro turno
|
||
Depende de: metros/hora reais, tempo entre etapas, e quanto do tempo do designer
|
||
é retrabalho de arquivo ruim.
|
||
|
||
### E2 · SPOT automático
|
||
Depende do teste em `dtf-teste-branco-automatico.pdf`.
|
||
|
||
### E3 · PC central como servidor de RIP
|
||
Depende de: configuração atual, custo da licença (é **por PC**), e memória que o
|
||
RIP consome.
|
||
|
||
---
|
||
|
||
## Bloqueios · o que trava qual tarefa
|
||
|
||
| Tarefa | Espera por | De quem |
|
||
|---|---|---|
|
||
| B3 · pré-flight | os cinco arquivos de exemplo | designers |
|
||
| B3 · regras de choke | valor do choke e espessura mínima | designers |
|
||
| D5 · meta | meta geral ou por causa? | Marcus |
|
||
| E1 · terceiro turno | metros/hora reais | sala |
|
||
| E2 · SPOT | resultado do teste | sala |
|
||
| E3 · RIP central | config e licença do PC central | Wagner |
|
||
|
||
**Nada no bloco A, B1, B2, C e D1 a D4 está bloqueado.** Dá para chegar até o
|
||
kanban funcionando sem nenhuma dessas respostas.
|
||
|
||
---
|
||
|
||
## Ordem sugerida de trabalho
|
||
|
||
```
|
||
semana 1 A1 · A2 · A3 · A4
|
||
semana 2 B1 · B2
|
||
semana 3 B3 · B4 · B5 ← portal no ar, recebendo 24h
|
||
semana 4 C1 · C2 ← arquivo caindo na pasta sozinho
|
||
semana 5 D1 · D2
|
||
semana 6 D3 · D4
|
||
semana 7 D5 · D6 ← kanban completo
|
||
semana 8+ medir · depois E
|
||
```
|
||
|
||
**Ao fim da semana 3 a Altus já recebe arte de madrugada e recusa arquivo ruim
|
||
automaticamente**, sem nada ter mudado na sala. É o primeiro ganho real.
|