Tasks | Pipeline Operacional

governanca todo

Fonte da verdade das tarefas do projeto. Cada task é uma nota individual T-XXX.md nesta pasta com frontmatter rico (status, owner, frente, prazo, prioridade, dependências, refs, tags).

Visão pipeline: abrir _bases/tasks-pipeline.base no Obsidian — kanban + 8 views diferentes.

Visão executiva read-only: TASKS.md (na raiz) — auto-gerada periodicamente a partir desta pasta.


Como criar uma task nova

  1. Abrir _template e copiar
  2. Salvar como T-{próximo-id}.md nesta pasta — próximo ID = maior atual + 1 (hoje: T-099)
  3. Preencher frontmatter completo (status, owner, frente, prazo, etc.)
  4. Preencher seção Critérios de conclusão com checkboxes verificáveis
  5. Linkar atas / specs / decisões relacionadas no body

Para atualizar: editar o frontmatter (mudar status, completed, effort_real, etc.) — a Base reflete imediatamente.


Convenções de frontmatter

Status

ValorSignificado
abertaAguardando início
em-progressoSendo executada agora
bloqueadaEsperando algo externo (descrever em notas operacionais)
pendenteAguardando trigger externo (data, evento, decisão de outrem)
concluidaCritérios atendidos. Preencher completed: YYYY-MM-DD
canceladaNão vai mais ser feita. Preencher motivo em notas operacionais

Prioridade

ValorCritério
criticaBloqueante de cliente, prazo em ≤3 dias, ou crise operacional
altaPrazo em ≤14 dias OU crítica para sprint atual
mediaDefault
baixaNice-to-have, sem prazo apertado

Frente

ValorQuando usar
anouk-internoTrabalho interno Anouk (governança, infra, processos)
anouk-clienteEntregável para cliente (Igor, Ricardo, etc.)
costalOperação Costal (Sienge, agentes, processos)
colliersOperação Colliers (CIB, CTS, CREMS)
geralCross-frente (não cabe em só uma)

Owner

Sempre slug — minúsculas com hífens. Exemplos: pedro, gabriel, antonio, rafael, blaschek, marcos, igor, axios.

Cada slug tem nota correspondente em pessoas.

Para múltiplos: usar co_owners: [outro-1, outro-2] (não duplicar no owner).

Origem

ValorQuando usar
reuniaoSurgiu de uma ata (link no body)
gapDe gaps
dependenciaDe dependencias
decisaoDe decisoes
specDe um discovery prep ou spec
definicaoDe DEFINICOES (rituais, processos)
manualCriada ad-hoc, sem origem documentada

Views disponíveis (Base tasks-pipeline)

A Base _bases/tasks-pipeline.base tem 19 views organizadas em grupos:

Vista geral:

  1. Todas as tasks

Por status (kanban manual — abrir uma após a outra):

  1. 🟡 Em progresso
  2. 🔴 Bloqueadas
  3. ⚪ Abertas
  4. ⏸️ Pendentes
  5. ✅ Concluídas
  6. ⚠️ Críticas

Por owner:

  1. 👤 Pedro
  2. 👤 Rafael
  3. 👤 Antônio
  4. 👤 Gabriel

Por frente:

  1. 🏢 Frente Colliers
  2. 🏗️ Frente Costal
  3. 🧠 Frente Anouk Interno
  4. 🤝 Frente Anouk Cliente

Por contexto / urgência:

  1. 🚀 Sprint semana 2
  2. 📅 Hoje + Imediato
  3. 📅 Esta semana
  4. 🔗 Recém-modificadas

Notas técnicas sobre Bases (debug 27/04):

  • Filtros usam acesso direto a propriedadestatus == "aberta", owner == "pedro", frente == "colliers", priority == "critica". Funciona perfeitamente em filtros de view; também funciona em order: para mostrar a propriedade como coluna da tabela.
  • file.content.contains() não inclui o frontmatter — só o body. Usar acesso direto a propriedade para filtrar por status/owner/frente/etc.
  • file.extension == "md" não funciona nesta versão (erro: “Não foi possível encontrar extension no tipo File”). Outras Bases do vault têm esse mesmo bug latente — corrigir quando der tempo.
  • Strings com : precisam de aspas simples se forem usadas em filter inline (ex: 'file.content.contains("chave: valor")').
  • type: cards / groupBy / formulas / properties: displayName — não suportados. Para “kanban”, abrir as 4 views por status sequencialmente.
  • Drag-and-drop entre status — não disponível em Bases. Para mudar status, edita o frontmatter da nota T-XXX.md (a Base reflete imediatamente).
  • Convenções completas registradas em runbook-tasks §Convenções de sintaxe Bases.

Estrutura desta pasta

00-projeto/tasks/
├── tasks.md           ← este arquivo (folder note)
├── _template.md       ← template para nova task
├── T-001.md
├── T-002.md
├── ...
└── T-098.md

Próximo ID livre: após T-098, usar T-099.


Manutenção

  • Re-migrar do TASKS.md histórico (idempotente): python 99-operacao/scripts/migrate-tasks-to-notes.py
  • Exportar dashboard read-only para TASKS.md raiz (a implementar): python 99-operacao/scripts/export-tasks-dashboard.py
  • Validar consistência (a implementar): script que checa IDs duplicados, owners inválidos, prazos malformados, dependências circulares

Ver também


Estrutura criada em 2026-04-27 (T-099) substituindo TASKS.md como tabela única. Migração de 98 tasks em 1 passada.

Tasks não indexadas

141 items neste arquivo.