User story
Como liderança de engenharia da org, eu quero medir o uso real de agentes de IA (Claude Code / Codex) por repositório e time — cruzado com os sinais de durabilidade que o Iris já produz — para responder "onde gastamos esforço de IA e isso virou código durável vs. virou retrabalho?", sem nunca expor ou inferir uso por indivíduo.
A inversão central é de privacidade: a identidade morre na borda — a CLI parseia o transcript localmente, descarta todo o conteúdo e sobe só agregados anônimos. Nenhum transcript cru cruza a rede.
Acceptance criteria
Scope / non-goals
Dentro: captura de usage/modelo/duração/contagem de tool calls e sub-agentes; atribuição a repo/time; agregação; exposição com supressão.
Fora (permanente): ranking, score ou comparação de indivíduos (Princípio #2); exposição por dev a gestores; upload de texto de prompt/resposta, código ou argumentos de tool; timestamp exato.
Garantia "impossível por construção"
- Identidade (user/email/host/paths) nunca cruza a rede — descartada na máquina do dev antes do upload.
- A menor granularidade no banco é (repo, dia, modelo) — não existe coluna
user. Nem um DBA com acesso total responde "quanto o fulano usou".
- Texto de conversa/código vive todo em
message.content[]; o parser só lê content[].type para contar tool calls — nunca .text/.thinking/.input.
- Exposição suprime células de time/repo abaixo de N membros (k-anonimato pelo organograma).
Se encaixa em qual estágio?
Fora do escopo atual — justificar. Conflita hoje com o Princípio #7 (Vendor-Agnostic Intelligence) e o Non-Goal permanente "vendor-specific AI telemetry". A issue filha do ADR reabre essa decisão; uma vez fechada, o trabalho passa a ser Stage 3 (cross-system correlation).
Issues filhas
Ordem de execução (cada uma bloqueia as seguintes):
Follow-ups registrados, não criados ainda:
- Adapter Codex (formato a confirmar em transcript real)
- [METRIC] "durabilidade por token" / eficiência de esforço-IA — só depois do telemetry existir, via
metric.yml
- Pseudônimo rotativo para k-anonimato por contribuidores distintos (só se a inferência virar problema)
User story
Como liderança de engenharia da org, eu quero medir o uso real de agentes de IA (Claude Code / Codex) por repositório e time — cruzado com os sinais de durabilidade que o Iris já produz — para responder "onde gastamos esforço de IA e isso virou código durável vs. virou retrabalho?", sem nunca expor ou inferir uso por indivíduo.
A inversão central é de privacidade: a identidade morre na borda — a CLI parseia o transcript localmente, descarta todo o conteúdo e sobe só agregados anônimos. Nenhum transcript cru cruza a rede.
Acceptance criteria
Scope / non-goals
Dentro: captura de
usage/modelo/duração/contagem de tool calls e sub-agentes; atribuição a repo/time; agregação; exposição com supressão.Fora (permanente): ranking, score ou comparação de indivíduos (Princípio #2); exposição por dev a gestores; upload de texto de prompt/resposta, código ou argumentos de tool; timestamp exato.
Garantia "impossível por construção"
user. Nem um DBA com acesso total responde "quanto o fulano usou".message.content[]; o parser só lêcontent[].typepara contar tool calls — nunca.text/.thinking/.input.Se encaixa em qual estágio?
Fora do escopo atual — justificar. Conflita hoje com o Princípio #7 (Vendor-Agnostic Intelligence) e o Non-Goal permanente "vendor-specific AI telemetry". A issue filha do ADR reabre essa decisão; uma vez fechada, o trabalho passa a ser Stage 3 (cross-system correlation).
Issues filhas
Ordem de execução (cada uma bloqueia as seguintes):
/api/ingest/usage+ schemausage_rollup(após [FEAT] ADR + reabrir Princípio #7 — exceção para telemetria de vendor sob privacy-by-construction #66)Follow-ups registrados, não criados ainda:
metric.yml