Skip to content

[FEAT] CLI: as duas flags que o worker precisa #223

Description

@cpenaforte-clickbus

User story

Como o worker de coleta, eu quero mandar o digest que analisei e não mandar produção individual por
pessoa
, para que a idempotência funcione e a centralização não mude a condição de coleta por efeito
colateral.

Acceptance criteria

--refs-digest

  • O CLI aceita o digest calculado pelo worker e o inclui no payload do push_metrics
  • Sem a flag, o payload sai exatamente como sai hoje — o agente local não vê diferença

A flag que desliga o author_velocity

  • Com ela, o metrics.json não traz a chave author_velocity
  • Sem ela, o comportamento é o de hoje — o agente local segue emitindo, e esta issue não o altera
  • O worker roda com a chave desligada

Por que a segunda flag existe

O metrics.json carrega uma chave que junta identidade e produção individual: author_velocity, que
traz por pessoa o nome, o e-mail, os commits, as linhas por semana e o percentual de commits com
trailer de IA (iris/analysis/author_velocity.py, iris/reports/writer.py:55). É a única com essa
forma — varridos iris/analysis, iris/metrics, iris/reports e iris/platform, nenhum outro módulo
emite e-mail.

O CLAUDE.md lista "individual developer ranking, scoring, or productivity tracking" como não-objetivo
permanente e exige quatro condições para telemetria subir — "parsed locally, identity discarded at
the edge, only aggregates uploaded, repo/team grain with k-anonymity"
, fechando com "anything short of
all four stays out"
. A chave falha em duas: a identidade não é descartada na borda, e o que sobe não é
agregado no grão de repositório.

O argumento é de alcance: no caminho local a emissão é opt-in por máquina e alcança só o que cada
pessoa instalou; centralizar sem desligar a estenderia aos 598 repositórios da organização, sem ação de
ninguém.

Scope / non-goals

Fora: tirar a chave do engine inteiro. Se ela deve sair, é decisão do Iris e fica registrada no DD
como possibilidade futura, não como pedido.

Se encaixa em qual estágio?

Stage 2 — Ingestion: reliability of CLI → /api/ingest pipeline, e Princípio #2 (nunca ranquear
indivíduos).

Implementation notes

O push_metrics de hoje monta repository, window_days, remote_url, cli_version, github_user e
active_users — sem o campo novo a idempotência da §3.2 não existe. O active_users carrega nome e
login do GitHub, sem e-mail e sem número por pessoa, e continua sendo enviado.

O ingestSchema da rota usa .passthrough(), então esta issue pode ser mergeada antes da rota
persistir o campo, sem quebrar nada.

Links

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions