[FEAT] Piloto: resolver o environment e fechar as cinco medições

[cpenaforte-clickbus]

User story

Como responsável pelo rollout, eu quero rodar o worker em paralelo com o agente local por uma semana,
para resolver a única pergunta em aberto do desenho e fechar as cinco medições antes de ligar o
schedule.

A pergunta em aberto, que fecha no primeiro run

• Confirmar em qual repositório o environment declarado no worker resolve — o do caller ou o do
  workflow chamado. A documentação do GitHub não fixa isso, e o modelo de secrets da §8 depende dele.
  A doc só diz: "If you include environment in the reusable workflow at the job level, the
  environment secret will be used, and not the secret passed from the caller workflow."

As cinco medições

• Paridade: metrics.json do worker contra execução local nos mesmos repositórios e no branch
  padrão, campo por campo, pelo comparador. É critério de bloqueio (§7) — divergência aqui muda o
  histórico do produto em silêncio.
  Os dois lados rodam o mesmo SHA do engine: o worker usa o do job.workflow_sha, e a execução local tem de usar esse mesmo commit, não a versão instalada na máquina. O engine passou de v1.6.1 a v1.10.0 desde que este plano foi escrito, e [METRIC] Origin classifier: attribution by evidence source (email domain, agent author markers) #234 e [METRIC] Churn: exclude lockfiles and generated files from the churn family #235 mudam métricas de propósito — comparar versões diferentes mede a diferença entre elas, não a paridade.
• Maior idade de análise por uma semana, que fixa o threshold do watchdog e substitui o palpite de 30 h
• Leitura de refs dentro do runner, contra os 29,7 s medidos fora dele
• Tempo do push por repositório, com a resolução de identidade do active_users dentro — é o termo
  que a tabela de custo da §3.5 não cobre, porque as medições cronometraram a análise e não o push
• Tempo de ciclo com 2 vCPU, que confirma se o gargalo continua sendo rede

Como

Por workflow_dispatch, com o agente local ainda ligado. Nada é desligado nesta fase.

Acceptance criteria

• As cinco medições registradas com o comando que as regenera
• A resolução do environment documentada em docs/DECISIONS.md
• Threshold do watchdog fixado com número medido, substituindo as 30 h provisórias
• Paridade satisfeita, com os dois lados no mesmo SHA do engine e esse SHA registrado — ou, se divergir, a causa identificada antes de qualquer rollout

Timebox

Uma semana de execução em paralelo.

Se encaixa em qual estágio?

Stage 2 — validação antes de mudar a fonte do dado do produto.

Links

• DD 0010 §6 (Fase 3) e §7 (documento interno, acesso restrito)
• Parte de: Fases 3 e 5 — Piloto e rollout #212

O agente local durante o piloto

• Confirmar que os três caminhos locais seguem funcionando sem alteração e sem reinstalação:
  prepare-commit-msg, post_commit_push.sh e iris agent
• Confirmar a coexistência: um repositório pode receber, no mesmo dia e na mesma janela, uma análise
  local e uma do worker. Isso é histórico somado, não corrompido — a plataforma lê a execução
  mais recente por repositório e janela, e a cobertura conta o repositório como coberto por qualquer
  um dos dois.

Bloqueado por

O piloto só faz sentido com o worker inteiro de pé — é ele que está sendo medido:

• [FEAT] Ciclo: seleção, clone paralelo, análise e push #222 — o ciclo completo, que por sua vez fecha a Fase 1 inteira
• RocketBus/iris-actions#1 — o caller, porque o environment a confirmar é o dele
• RocketBus/billing#64 — o GitHub App, sem o qual não há credencial para cunhar
• [DEBT] PR enrichment degrades silently when the GraphQL step fails; the report carries no signal #236 — o sinal de degradação do enriquecimento de PR. Sem ele, um 504 transitório do GraphQL em qualquer um dos dois lados aparece como divergência de paridade em merge_strategy_* e flow_*, e nada no metrics.json diz qual run degradou: o critério de bloqueio não distingue bug do worker de falha de rede

Não depende da Fase 4: o watchdog pode subir em paralelo, e o threshold que esta issue mede é
justamente o que vai configurá-lo.