Axios V2 | Jobs Plan
Plano dos crons V2 — manter os 6 atuais (com 1 correção crítica) e adicionar 5 novos para suportar os 8 gatilhos do proactivity-playbook. Total V2: 11 crons.
Snapshot V1 (situação atual — 25/04)
| ID | Job | Cron | Entrega | Estado |
|---|---|---|---|---|
| 08093fc3 | axios-daily-drive-sync-before-routine | 03:00 diário | Telegram | ✅ ok |
| 30ef6cb8 | axios-daily-brief | 08:00 dias úteis | Slack C0ASPAV6LDR | ✅ ok |
| 1f220795 | axios-daily-brief-telegram-status | 08:05 dias úteis | Telegram | ✅ ok |
| 7c50555d | axios-slack-governance-monitor | 09/12/15/18h dias úteis | Telegram | ❌ error persistente |
| e288ff11 | axios-weekly-consolidation | sex 13:30 | Slack C0ASPAV6LDR | ✅ ok |
| bae363b8 | axios-weekly-consolidation-telegram-status | sex 13:35 | Telegram | ✅ ok |
Plano V2 — 11 jobs total
Jobs mantidos (sem mudança) — 4
| Job | Por que manter |
|---|---|
| daily-drive-sync-before-routine | Funciona perfeitamente; é a fundação dos outros |
| daily-brief (Slack 08:00) | Output visível, time depende — só ajustar conteúdo (ver §Conteúdo) |
| weekly-consolidation (Slack sex 13:30) | Idem; output visível ao time |
| daily-brief-telegram-status + weekly-consolidation-telegram-status | Confirmações para Pedro — manter como estão |
Jobs corrigidos — 1
slack-governance-monitor (id 7c50555d) — PRIORIDADE ALTA
Estado: error persistente — ✉️ Message failed.
Hipótese diagnóstica:
- Telegram tem limite de ~4096 caracteres por mensagem.
- Job possivelmente acumula muitos sinais e tenta enviar em uma única mensagem grande → falha.
- Ou retry sem backoff está congestionando a API.
Correção V2:
- Quebrar mensagens longas em chunks de ≤3500 caracteres (margem para markdown overhead Telegram).
- Adicionar retry exponencial (2s, 4s, 8s) com fallback para gravar em
agentes-core/axios/outputs/governance-monitor-fallback.mdse Telegram falhar 3×. - Reduzir frequência: mudar de 4×/dia (09/12/15/18) para 3×/dia (10/14/17) — alinha com janelas de uso ativo do Slack.
- Filtro mais conservador: só capturar sinais classificados com confiança ≥0.7 (eliminar falsos positivos de “decisão” frágeis).
- Resumir antes de enviar: top 3 sinais mais materiais por janela, não tudo.
Validação: rodar 3 dias antes de declarar estável.
Jobs novos — 5
V2-1 — axios-meeting-prep-trigger (T-4h antes de reunião)
- Quando: dispara quando há reunião confirmada em MEETINGS dentro das próximas 4h, excluindo rituais recorrentes
- Implementação: cron a cada 30min entre 06:00 e 19:00, dias úteis. Lê MEETINGS, calcula proximidade.
- Output: Telegram Pedro
🎯 prep T-4h: <reunião>com mini-brief (cf. proactivity-playbook gatilho 1) - Idempotência: marca em
agentes-core/axios/state/prep-sent.jsono ID da reunião + data; não duplicar
V2-2 — axios-meeting-followup-trigger (T+30min após reunião)
- Quando: dispara 30 min após o
end_timede uma reunião listada em MEETINGS - Implementação: cron a cada 30min entre 09:00 e 20:00, dias úteis
- Output: Slack DM Pedro com proposta de promoção de sinais (cf. proactivity-playbook gatilho 2)
- Idempotência: marca
followup-sent.json
V2-3 — axios-task-overdue-monitor (diário 09:00 dias úteis)
- Quando: todo dia útil às 09:00 (após daily-brief)
- Implementação: lê TASKS, filtra
prazo < hoje AND status != concluida, classifica por dias atrasados - Output:
- 1-3 dias atrasada: Slack DM ao owner (se Anouk)
- 4-7 dias: Slack DM Pedro CC owner
-
7 dias: Telegram Pedro com escalação
- Idempotência: lembrar a mesma tarefa só 1×/semana (evitar nag)
V2-4 — axios-morning-briefing-pedro (08:00 dias úteis)
- Quando: todo dia útil às 08:00 (paralelo ao daily-brief Slack — daily-brief é para o time, este é para Pedro)
- Implementação: consolida em 3-5 bullets curtos para Pedro
- Output: Telegram Pedro
☀️ briefing <data>(cf. proactivity-playbook gatilho 6) - Diferença vs daily-brief: daily-brief Slack é institucional para o time; morning-briefing Telegram é pessoal para Pedro com 1 alerta crítico + 1 oportunidade
V2-5 — axios-vault-integrity-check (diário 03:30 após sync)
- Quando: todo dia às 03:30 (depois do drive-sync das 03:00)
- Implementação: roda checks listados no proactivity-playbook gatilho 8 (links quebrados, frontmatter desatualizado, IDs duplicados, etc.)
- Output:
- 0 problemas: silêncio
- 1-3 problemas: relatório curto Telegram Pedro
- 4+ problemas: relatório consolidado em
outputs/vault-integrity-report.md+ Telegram com link
Tabela síntese V2
| # | Job | Cron V2 | Canal | Origem |
|---|---|---|---|---|
| 1 | daily-drive-sync-before-routine | 0 3 * * * | Telegram | mantido |
| 2 | vault-integrity-check | 30 3 * * * | Telegram | NOVO |
| 3 | morning-briefing-pedro | 0 8 * * 1-5 | Telegram | NOVO |
| 4 | daily-brief | 0 8 * * 1-5 | Slack | mantido |
| 5 | daily-brief-telegram-status | 5 8 * * 1-5 | Telegram | mantido |
| 6 | task-overdue-monitor | 0 9 * * 1-5 | Slack/Telegram | NOVO |
| 7 | slack-governance-monitor | 0 10,14,17 * * 1-5 | Telegram | CORRIGIDO (era 09/12/15/18) |
| 8 | meeting-prep-trigger | */30 6-19 * * 1-5 | Telegram | NOVO |
| 9 | meeting-followup-trigger | */30 9-20 * * 1-5 | Slack DM | NOVO |
| 10 | weekly-consolidation | 30 13 * * 5 | Slack | mantido |
| 11 | weekly-consolidation-telegram-status | 35 13 * * 5 | Telegram | mantido |
Conteúdo do daily-brief — refinamento V2
O daily-brief (Slack canal C0ASPAV6LDR às 08:00) é o output mais visível. V2 refina formato:
V1 atual (suposição — confirmar com saída real)
- Lista geral de tarefas ativas
- Reuniões da semana
- Riscos abertos
V2 proposto
🌅 Daily Brief — <data>
📅 Hoje
- <reunião 1> @ <horário> — <participantes>
- <reunião 2> @ <horário>
(se nada: "sem reuniões agendadas hoje")
🎯 Sprint atual (semana <N>)
- <prioridade da semana em 1 linha>
- <2-3 tarefas prioritárias da semana com owner>
⚠️ Atenção
- <risco crítico se houver>
- <gap material recém-aberto>
(omitir seção se nada material)
📊 Cobertura assessment
- <X áreas com discovery prep / 23 (Colliers)>
- <Y domínios em discovery / 12 (Costal)>
Princípio: se uma seção não tem conteúdo material, omitir (não escrever “nenhum risco hoje” — só silêncio).
Recuperação de erros (regra V2)
Qualquer job que falha 2× consecutivas:
- Pausa automática (não tentar 3ª vez no mesmo dia)
- Reporta erro detalhado no Telegram para Pedro com:
- Nome do job
- Timestamp
- Stack trace ou mensagem de erro
- Sugestão de causa raiz
- Permanece pausado até Pedro fazer “ack” via Telegram (responder com
/resume <job>)
Isso resolve o caso atual do slack-governance-monitor que continuou tentando com erro persistente.
Onde implementar
Código vive em /root/.openclaw/workspace/jobs/ (no servidor OpenClaw VPS, fora do vault). Documentação acompanha em agentes-core/axios/jobs/<job>.md e <job>.py neste vault, mas o runtime é OpenClaw.
Quando os 5 novos jobs forem implementados, atualizar:
agentes-core/axios/jobs/crontab.txt— adicionar entradas V2- Criar
<job>.py+<job>.mdpara cada novo job - Atualizar jobs.md (folder note) com os 5 novos