Lead Time & Capacity

Lead time é medido via git tags pareadas. Cada cenário ganha duas marcas no histórico: quando o trabalho começou (red) e quando os testes ficaram verdes (green). ADRs ganham uma marca quando aceitos.

Schema de tags

• lead/<id>/red — work-started. Spec escrito, testes vermelhos.
• lead/<id>/green — work-done. Implementação completa, testes verdes.
• decision/<id> — ADR aceito (decisão técnica).

Lead time = green − red (tempo entre primeira escrita do spec e implementação verde).

Comandos do script

./scripts/lead-time.sh expõe quatro comandos:

• ./scripts/lead-time.sh red <id> — cria tag lead/<id>/red no HEAD. Marca início do trabalho.
• ./scripts/lead-time.sh green <id> — cria tag lead/<id>/green no HEAD. Marca conclusão.
• ./scripts/lead-time.sh report — relatório consolidado (lead time por cenário, throughput médio).
• ./scripts/lead-time.sh wip — lista cenários com red mas sem green (work-in-progress).
• ./scripts/lead-time.sh throughput [days] — cenários concluídos no período (default últimos 30 dias).

Workflow recomendado

1. Scenario criado (doc .md + spec .spec.ts red) → roda red <id>.
2. Impl session (subagent fanout) → testes ficam verdes.
3. Verifica green (npm test) → roda green <id>.
4. ADR técnico aceito → roda decision <id> (sem par red/green; ADRs são pontos).

A linha do tempo do repo (git log) fica anotada com marcos. Relatórios saem do próprio git sem ferramenta externa.

Snapshot estático

Status atual (2026-06-03):

• 34 green — cenários 000-026 + wa-001/002/003/004 + landing-001/002/003.
• 0 WIP red — specs passam contra impl real ou mock; backlog técnico fica em /cpo/030-next/.
• 10 ADRs aceitas — 001-010.

Snapshot detalhado (datas, lead times por cenário, throughput) vive em /kpis/, mantido por outro agente. Esta página explica o modelo; /kpis/000-dashboard/ mostra o dado.

Cross-link

Workflow descrito em AGENTS.md ## Lead time tracking. Script em scripts/lead-time.sh no repo root.