Rotinas¶
Uma rotina é o agendamento: a casca mais fina do harness, e a única peça que dispara sozinha. Ela não sabe fazer nada — só manda executar um workflow na hora marcada.
Esta página diz quem dispara o quê. O que cada workflow faz por dentro (fases, modelos, diagrama) está em workflows.
Nuvem × local — a diferença é operacional¶
| Roda onde | Quando funciona | |
|---|---|---|
| nuvem | infra do Claude, sandbox com clone do repo | sempre |
| local | sua máquina | só com o computador ligado e conectado |
Rotina de vigilância que mora no local é frágil por natureza: o dia em que a máquina está fechada é justamente um dia sem ninguém olhando — e ninguém percebe a ausência, porque falta de alerta se parece com ausência de problema.
Duas consequências do sandbox de nuvem: nada de estado em arquivo (o sandbox é descartado; a
memória entre runs é o board do Linear e o mem0) e CLI sem auth interativa (railway ssh não
roda — inspeção ao vivo é exclusiva de sessão interativa).
As rotinas de monitoração e investigação¶
São duas — e só existem duas: rotina é pra trabalho que precisa acontecer sem ninguém pedir.
O resto do harness roda por comando (/scout, /reach,
/build, /monitor), que é você chamando na hora que quer:
| Rotina | Onde | Dispara | Estado |
|---|---|---|---|
| rotina-scout-log | nuvem, diária 21h | o workflow scout-log — varre o log, 4 leituras em paralelo (3 lentes + triagem, que cria as issues), gate comunica | ativa |
| rotina-investigate-bug | local, dias úteis 9h | o workflow investigate-bug — investiga os bugs de To scout e move pra Reach |
ativa |
As duas formam um par, e o gate entre elas é humano: a de 21h constata e registra no In-box,
alguém promove pra To scout, e a das 9h pega dali. Nenhuma decide sozinha o que merece investigação, e
nenhuma promove o próprio resultado pra frente.
Por que só duas. Vigilância de log precisa rodar sem ninguém pedir — o valor está em olhar no dia em que ninguém suspeita de nada. Já planejar e construir precisam de decisão humana no meio: viram comando, não rotina. Rotina que faz trabalho que exige aprovação só produz fila de coisa esperando você.
As outras rotinas¶
Todas pausadas de propósito durante a reconstrução do harness.
| Rotina | Onde | Horário | Dispara |
|---|---|---|---|
providers-monitoring |
nuvem | 8h | — · redundante (virou lente do scout-log) |
ci-monitoring |
nuvem | 20h | — · redundante (virou lente do scout-log) |
Daily Linear sync from meeting notes |
nuvem | dias úteis 10h30 | sincroniza o Linear a partir de notas de reunião |
rotina-reach-to-scout |
local | dias úteis 7h | — · substituída pelo comando /reach (mesma fila, agora sob demanda) |
rotina-scout-backlog |
local | dias úteis 8h | varredura do backlog → até 3 execuções em worktree |
rotina-scout-triagem-grupos |
local | horária, 9h–18h | triagem dos grupos de WhatsApp de tech |
rotina-scout-tech-debt |
local | dias úteis 21h30 | dívida técnica no código recente |
rotina-monitor-gate |
local | 22h30 | digest do dia · obsoleta (o digest nasce dentro do workflow) |
rotina-monitor-release |
local | sexta 17h | briefing semanal e página de release |
Três dívidas nessa lista¶
providers-monitoring e ci-monitoring ficaram redundantes — as duas skills agora rodam
dentro do workflow scout-log. São candidatas a apagar, não a reativar: rotina pausada é
armadilha, alguém religa em seis meses e passa a receber o mesmo parecer duas vezes, em horários
diferentes, com prioridades que não conversam.
rotina-monitor-gate está obsoleta duas vezes — descrevia um digest a partir da fila
gate-inbox.jsonl, que saiu de uso quando o Gate passou a ler o board, e saiu de novo quando o
digest passou a nascer dentro do workflow.
A investigate-bug nasceu local, e o lugar dela é a nuvem. Foi criada em 28/07 como rotina
local (dias úteis 9h) porque é o que dá pra criar por ferramenta — rotina de nuvem só pela UI. Como
ela processa uma fila (e não vigia nada), rodar local é menos grave que numa rotina de
vigilância: o dia em que a máquina está fechada a fila só espera. Ainda assim, mover pra nuvem
remove a dependência da sua máquina estar ligada às 9h.
Quando algo merece rotina¶
Rotina é pra trabalho que precisa acontecer sem ninguém pedir. Se a resposta for "quando eu lembrar", não é rotina — é comando sob demanda.
| Padrão | Use | Por quê |
|---|---|---|
| vigilância periódica (log, saúde, backlog) | rotina | o valor está em olhar mesmo quando ninguém suspeita de nada |
| reação a evento (PR aberto, merge, tag) | event-driven | rotina agendada olharia tarde e olharia à toa |
| investigação, planejamento, implementação | sob demanda | precisa de contexto humano e de decisão no meio |
E o teste que evita rotina inútil: se ela rodar num dia sem novidade, o que ela entrega? Se a
resposta é "nada" ou "uma mensagem verde que ninguém lê", ela vai ser ignorada justamente no dia em
que tiver algo — e o registro de que checou e estava limpo precisa existir em algum lugar (no
scout-log, é a cobertura da leitura do dia).
Encadeamento em vez de horário¶
O jeito antigo de coordenar era horário: uma rotina às 20h, outra às 21h, e a de 21h contava que a de 20h tinha rodado. Isso quebra em silêncio — se a primeira falha, a segunda roda com dado velho achando que está tudo bem.
O jeito atual é uma rotina, um workflow, fases em sequência. A ordem passa a ser garantida em vez de convencionada, e a falha aparece num lugar só.