ADORSYS-GIS / ADORSYS-GIS/lightbridge-governance

[Epic]: AI-powered IDE observability — adoption and suggestion-acceptance telemetry

Open
#95 0 comments 0 reactions 0 assignees View on GitHub
epic
Dominant language
Rust
Stars
1
Forks
2
Avg merge
13h 13m
Merged PRs (30d)
110

Description

## Summary
A new commercial product line: selling AI-powered-IDE observability — who uses AI, and how often AI-agent code proposals are accepted. This epic tracks the connector-by-connector, layer-by-layer buildout across vendors, plus the cross-vendor normalization, privacy, and outcome-correlation work that differentiates it from existing DevEx tooling vendors.

## Intent / Source of truth
2026-08-13 cross-repo backlog consolidation. Load-bearing architectural finding, recorded here verbatim:

> A gateway/proxy can NEVER observe acceptance. Accept / reject / edit-then-accept happens client-side inside the IDE process, after the HTTP response has already returned. Even GitHub — who owns both the model backend and the extension — needs the extension to emit accept/dismiss events separately. Therefore the gateway gives us usage, cost, tokens, latency and per-user request attribution; acceptance requires (a) the vendor's own OTLP emission, (b) the vendor's admin/analytics REST API, or (c) our own IDE extension. Also: the OpenTelemetry GenAI semantic conventions (moved to `open-telemetry/semantic-conventions-genai`, still `Status: Development`, no tagged release) standardize token usage, operation duration and agent/tool spans but define **nothing** for code-suggestion acceptance. There is no standard to lean on — we must define the schema.

## Scope
- [ ] Ten child Stories (linked as sub-issues) covering: schema definition, per-vendor connectors (Claude Code, Copilot, Cursor, JetBrains/Q/Tabnine), cross-vendor normalization, privacy floor, retained-code counterweight, outcome correlation, and a first-party-extension feasibility spike
- [ ] Sequencing respected: the normalizer depends on ≥2 connectors landing; the privacy floor lands alongside the first connectors, not after; the extension spike is sequenced after connector stories prove demand with zero-plugin data

## Out of scope
- Building a first-party IDE extension itself (that's gated behind the spike's recommendation, story 10)
- Promising per-individual-user acceptance data from vendors whose APIs are aggregate-only (Copilot) — see story 3's explicit constraint

## Verification
Each child Story carries its own verification (dashboard panel, live API pull, or documented recommendation for the spike). Epic closes when all ten are closed or explicitly descoped with rationale.

## Risk assessment
Commercial/positioning risk: overselling "acceptance rate" without the denominator caveats per vendor would be an accuracy failure for an AI-governance vendor. Technical risk: dependency on lightbridge-governance#84 (OIDC issuer mismatch) blocking the Claude Code connector (story 2) until fixed.

## AI Usage Declaration
Drafted with AI assistance during the 2026-08-13 cross-repo backlog consolidation. A human owns intent, verification and consequences; acceptance criteria must be verified against the live system before this is closed.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.