overengineeringstudio / overengineeringstudio/effect-utils
otel-scrape: retire the bespoke telemetry registry in favor of Weaver composition
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 82
- Forks
- 2
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 121
Description
Problem
@overeng/otel-scrape still authors telemetry through a bespoke JSON registry and generator even though the shared TypeScript-first Weaver composition foundation has landed. This leaves two registry mechanisms and prevents the otel-scrape contract from participating in the shared semantic checks and projections.
Goal
Author otel-scrape telemetry through defineOtelContract, compose it through the Weaver registry, generate its Rust and TypeScript bindings from that authority, and remove the bespoke registry path.
Current status (2026-08-11)
- #867 landed otel-scrape and #881 landed the shared Weaver Layer-1/Layer-2 generator; the original foundation blockers are resolved.
genie/otel-scrape-registry.ts,context/otel-scrape/telemetry-registry.json, and their generated-binding path remain onmain.- No implementation PR is open.
- This same-repository migration is implementation-ready. It does not depend on compiled cross-workspace staging PR #953 or the generic committed-projection research in #1046.
Acceptance criteria
- All current otel-scrape spans, metrics, and attributes are authored through
defineOtelContract. - Rust and TypeScript bindings are emitted from the composed Weaver registry with reviewed byte or semantic parity.
- The bespoke JSON registry and generator are removed, including stale VRS/documentation references.
- Deterministic Genie freshness remains enforced.
-
weaver:check,weaver:diff, the generated-artifact checks, and otel-scrape Rust tests pass. - Exactly one telemetry authority remains for otel-scrape.
References
- Foundation: #881
- otel-scrape delivery: #867
- Distinct generic projection research: #1046
Posted on behalf of @schickling
| field | value |
|---|---|
agent_name |
🔄 co2-tide |
agent_session_id |
b11aaa26-d085-4ef3-adca-7a64735035c9 |
agent_tool |
Codex CLI |
agent_tool_version |
0.144.1 |
agent_runtime |
Codex CLI 0.144.1 |
agent_model |
unknown |
runtime_profile |
/nix/store/9pwivx3z8bh69fjrsziw62ggmipmi35p-coding-agent-runtime-profile/share/coding-agents/profile.json |
skills_manifest |
/nix/store/y9zyjnc2d5mkgm8p7pv5xd10prcha6z0-agent-skills-corpus/share/agent-skills/manifest.json |
worktree |
dotfiles/main |
machine |
mbp2025 |
tooling_profile |
dotfiles@unknown-dirty |
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with genie/otel-scrape-registry.ts and context/otel-scrape/telemetry-registry.json, then inspect the shared Weaver composition foundation and defineOtelContract usage from #881. Run weaver:check, weaver:diff, generated-artifact checks, and the otel-scrape Rust tests; done means the bespoke registry and generator are removed, bindings retain parity, and one Weaver authority remains.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, typescript
- Domain
- build-system, observability
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100