01 — Pipeline autônomo

State machine em rótulos. Do triage ao merge.

Cada estado é um rótulo no forge — qualquer monitor, em qualquer pod, retoma de onde o anterior parou. Sem coordenação adicional, sem ponto único ativo.

Máquina de estados

A vida de uma issue, em rótulos.

Cada estado é um rótulo persistido no próprio forge — a issue (e a PR derivada) carregam o estado no seu próprio metadado. Isso significa que qualquer monitor, em qualquer pod, consegue retomar de onde o anterior parou, sem coordenação adicional.

trilho da issue

~workflow:nova
       │
       ▼  stage 1 · classify
       │
~workflow:em_revisao
       │
       ├── veredito CLARO ───────────────► ~workflow:revisada
       │                                          │
       │                              ┌───────────┴───────────┐
       │                       intent │                       │ feature/bug/refactor
       │                              ▼                       ▼
       │                    ~workflow:decomposta      ~workflow:em_implementacao
       │               (architect abre 1                       │
       │                + checklist de derivadas)              │
       │                                                       ▼
       │                                              ~workflow:em_pr  ────►  trilho da PR
       │
       └── veredito VAGO ──► ~refine:N  +  refino por persona:
                                  │
                                  ├─ intent       → ~workflow:em_refinamento   (analyst)
                                  └─ feature/bug  → ~workflow:em_arquitetura   (architect/debugger)
                                          │
                                          ↕  ~workflow:aguardando_stakeholder
                                          │     (humano remove o rótulo p/ destravar)
                                          │
                                          ▼
                                   volta para ~workflow:nova
                                   (até 5 voltas; N ≥ 5  →  ~workflow:bloqueada)

trilho da PR

PR aberta em auto/issue-N
       │
       ▼
~review:pendente
       │
       ▼  reviewer-LLM persona
~review:em_andamento
       │
       ├── falha ──► fix + push  ──► reabre review
       │
       └── ok    ──► merge  ──► ~review:concluida
                                 │
                                 ▼  post-merge callback
                          follow-ups + episodic memory

rótulos auxiliares

~refine:0..5 — contador durável de refino
~attempt:0..3 — contador de re-claim do reaper
~prioridade:0..3 — reordena candidatos (PR herda da issue)
~by:<id> — owner do claim
~batch:<sha8> — lock distribuído (só com sharding ativo)
~workflow:bloqueada — hard block; exclui do auto-resume
~mention:processado — idempotência cross-tick

As seis estações

Cada etapa, uma decisão; cada decisão, um rótulo.

As etapas são roteáveis por 3 eixos independentes: qual worker, qual modelo, qual esforço de raciocínio. O painel [d] mostra a matriz inteira editável ao vivo.

Classify

persona: analyst · architect · debugger

A primeira leitura. Determina o tipo da issue (intent, feature, bug, refactor) e dá veredito CLARO ou VAGO. Escolhe a persona certa para o passo seguinte.

Refine

persona: analyst (intent) · architect (feature/refactor) · debugger (bug)

Reescreve título, corpo e critérios de aceite até que a issue esteja implementável. Até 5 rodadas, com contador persistido em rótulo. Pausa em aguardando_stakeholder quando há gap de produto real.

Decompose

persona: architect (apenas para intent)

Quebra uma intent ampla em entregáveis menores. Estratégia anti-flood: abre uma única issue derivada com checklist de próximas, e libera o leque conforme cada uma fecha.

Implement

persona: developer · qualquer engine da frota

Edita arquivos, instala dependências, roda apenas os testes impactados, comita e empurra. Resumível em-place; sessões acima do orçamento são promovidas a fresh. Despachado para o motor escolhido para esta etapa.

PR review

persona: reviewer

Brief unificado: lê estado real da PR (autor, reviewer, threads, último review, CI). Aprova, corrige e re-push, ou solicita mudanças. Sempre persona reviewer, independente do engine.

Follow-ups

persona: developer + episodic memory

Pós-merge: coleta TODOs, débitos e aprendizados; abre derivadas; injeta o contexto do PR mergeado na memória episódica para enriquecer o próximo turno.

Anatomia de um tick

A ordem importa.

Quando o pipeline acorda, ele NÃO começa lançando trabalho novo. Ele primeiro recolhe o que ficou para trás, libera capacidade, retoma o que estava em andamento — e só então classifica o que chegou de novo. Essa ordem é o que evita duplicação e perda.

tick(N)
  │
  ├─ ① reaper          — quem ficou parado em em_implementacao/em_andamento > ~45 min?
  │                     incrementa ~attempt:N; em N≥3, marca ~workflow:bloqueada.
  │
  ├─ ② reconcile       — quem completou (fire-and-forget)? Libera vaga ANTES de despachar.
  │
  ├─ ③ resume          — quem tem ~em_implementacao + entrada no ledger? Retoma.
  │                     Sessão acima do orçamento  →  promove a fresh.
  │
  ├─ ④ classify         — issues ~workflow:nova ganham o primeiro veredito.
  │
  ├─ ⑤ review/refine   — vagas vão p/ refino sob persona certa; claras seguem.
  │
  ├─ ⑥ implement/decompose — despachado para o engine escolhido p/ a etapa.
  │
  ├─ ⑦ pr_review       — só em PRs que este monitor reivindicaria
  │                     (auto/issue-* ou repos com human-PR review habilitado).
  │
  └─ ⑧ mentions         — roteia menções e comentários por papel:
                     issue+assignee  → ~workflow:nova
                     PR+qualquer     → brief unificado
                     comment dirigido → one-shot persona developer

prioridade

Rótulo ~prioridade:0..3 reordena candidatos (0 primeiro). PR herda a prioridade da issue ligada.

sharding

Com mais de um monitor, cada item vai para um shard determinístico via hash do número. Sem coordenação. Sem item duplicado.

backoff de auth

3 falhas seguidas de auth no worker pausam o alvo por um intervalo crescente. O tick passa adiante.

Quality-gate

Confia no CI quando ele existe. Roda a suíte quando ele não.

Repo COM CI

O reviewer espera o pipeline real

→Antes de despachar a review, consulta o status do CI no forge.
→Se PENDING, pula o tick e reconcilia no próximo — sem queimar capacidade.
→Se FAILING, corrige e dá push até passar (sem rodar a suíte localmente).
→Só quando o CI está GREEN, fecha o review.

Repo SEM CI

O reviewer roda a suíte ali mesmo

→Executa a suíte de testes completa no próprio pod do worker.
→Implementação roda apenas testes impactados (rápido).
→Review valida cobertura completa antes de aprovar.
→Vermelho = não merge. Sem teatro.

As inteligências do pipeline

Os mecanismos que tornam autônomo, autônomo de verdade.

Refinement gate

Antes de programar, o pipeline pede crítica. Por tipo de issue, uma persona reescreve até a tarefa estar implementável — ou pausa explicitamente em aguardando_stakeholder. Cinco rodadas máximas, contador durável no próprio rótulo.

Decomposição anti-flood

Quando o architect quebra uma intent, ele NÃO cria 20 issues de uma vez. Abre uma derivada + checklist. Conforme fecha, libera a próxima. O leque cresce no ritmo do progresso real.

Resume vs reaper

São dois mecanismos. Resume continua trabalho COMECADO e registrado. Reaper REIVINDICA trabalho parado por mais tempo do que o aceitável. Cada um com seu contador, seu teto e seu critério de bloqueio.

Mention routing

Menções e atribuições são roteadas por papel: issue+assignee injeta novo trabalho; PR+qualquer trigger lê estado real e age; comentário dirigido vira um-off. Idempotência cross-tick via rótulo processado.

Quality-gate adaptativo

Se o repo tem CI, o reviewer espera os checks e corrige até passar — sem rodar a suíte no pod. Se não tem CI, roda a suíte completa ali mesmo. Em CI pending, pula o despacho deste tick para não brigar contra um job que ainda vai terminar.

Cost guard por engine

Cada dispatch tem teto de custo em USD. Sessões longas são promovidas a fresh quando passam do orçamento. O ledger JSONL persistido sobrevive a scale-to-zero do worker — auditoria não evapora.