Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

spike(framework): prove whether native OTel adds value beyond the measurement journal

Open
#297 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active

Research direction

Use the issue's same-session Claude Code comparison as the starting point, examining native OpenTelemetry data alongside the local-file readings and published AIDD JSON Lines journal. Record fields, task and step attribution, correlation reliability, privacy boundaries, and duplicate-accounting risks for each source. Done means the evidence supports retaining or rejecting each integration, and any interoperability claim names a consumer and proves consent, reception, and total preservation.

Written by the indexing model from the issue text.

Description

Question

Does native OpenTelemetry data add information or interoperability that the shipped AIDD measurement journal cannot provide?

Current baseline

AIDD already reads the files AI tools write, enriches them with task and step attribution, and stores a published JSON Lines record locally. aidd-telemetry:01-cost is its first reader. Measurement requires project opt-in, a person may refuse it locally, and the record contract excludes prompts, code, and diffs.

A hosted destination may be chosen by the person with separate consent. No destination, transport, or OpenTelemetry route is mandatory.

Evidence required

  • Compare, on the same Claude Code session, native OTel data with the local-file reading and AIDD journal.
  • State for each source: available fields, missing fields, attribution to task and step, correlation reliability, privacy boundary, and risk of duplicate accounting.
  • Do not generalize the Claude result to another tool without equivalent evidence.
  • Name an actual destination or consumer that cannot use the published record contract, if interoperability is claimed as the value.

Decision outcomes

  • No material gain: retain the local journal and do not add an OTel receiver or exporter.
  • Better source data: propose only the bounded native-source integration, including precedence and deduplication with local readings.
  • Destination interoperability is necessary: propose only the output mapping, consent, delivery proof, and retained totals. JSON Lines remains the local source of truth.

Out of scope

  • Migrating local storage to OTel.
  • Selecting or embedding a hosted destination.
  • Collecting any field outside the published record contract.
  • Declaring an external total a billing amount without its provenance.

Acceptance criteria

  • One same-session comparison documents coverage, correlation, and duplicate handling for native OTel and the local journal.
  • The outcome states whether native OTel changes a user-relevant decision, with evidence.
  • Any external-output proposal names its consumer and proves consent, reception, and total preservation.
  • The result explicitly retains or rejects each candidate integration; no transport is adopted by implication.
Dominant language
TypeScript
Stars
481
Forks
45
Avg merge
19h 38m
Merged PRs (30d)
108

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ai-driven-dev/framework

All issues in ai-driven-dev/framework

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.