Decide what a metric is in AIDD, before anyone writes an emitter. #297 cannot be specified until this closes.
Why this blocks
#297 (usage metrics) inherited a decision record — OpenTelemetry, spans, local-first collector — from a telemetry thread that never produced a line of code. The decisions were made about a mechanism before the entity was defined. The three questions below have no answer today, and every one of them changes the mechanism.
The three questions
What is the observed unit? A skill run, an action, a session, or a need traced across gestures. A span per skill run and a span per session are different schemas, different volumes, different privacy exposure.
Who consumes the data? The user, reading their own token spend locally. A team lead, comparing adoption. The framework maintainer, seeing which skills are dead. Each consumer implies a different sink: a local file, a shared collector, an opt-in upload. The current record says "local-first, no SaaS" without naming who reads it.
Which skills exploit it, and what do they need as input? A token-budget optimizer, a dead-skill detector, a next-gesture recommender. A skill that reads traces has a stricter contract on the schema than a dashboard does.
Method
Run aidd-refine:01-brainstorm on this issue. The output is a written record, not a decision made in conversation.
Acceptance criteria
Prior art in this repo
plugins/aidd-refine/hooks/condense-stats.js already reads the session transcript and approximates token usage. It is the closest thing to a metric today, and it is not telemetry.- No OpenTelemetry code exists anywhere in the repo (checked 2026-07-10 on
next).
Decide what a metric is in AIDD, before anyone writes an emitter. #297 cannot be specified until this closes.
Why this blocks
#297 (usage metrics) inherited a decision record — OpenTelemetry, spans, local-first collector — from a telemetry thread that never produced a line of code. The decisions were made about a mechanism before the entity was defined. The three questions below have no answer today, and every one of them changes the mechanism.
The three questions
What is the observed unit? A skill run, an action, a session, or a need traced across gestures. A span per skill run and a span per session are different schemas, different volumes, different privacy exposure.
Who consumes the data? The user, reading their own token spend locally. A team lead, comparing adoption. The framework maintainer, seeing which skills are dead. Each consumer implies a different sink: a local file, a shared collector, an opt-in upload. The current record says "local-first, no SaaS" without naming who reads it.
Which skills exploit it, and what do they need as input? A token-budget optimizer, a dead-skill detector, a next-gesture recommender. A skill that reads traces has a stricter contract on the schema than a dashboard does.
Method
Run
aidd-refine:01-brainstormon this issue. The output is a written record, not a decision made in conversation.Acceptance criteria
Prior art in this repo
plugins/aidd-refine/hooks/condense-stats.jsalready reads the session transcript and approximates token usage. It is the closest thing to a metric today, and it is not telemetry.next).