Story: Clean ores.telemetry to the component clean standard
Table of Contents
This page documents a story in Sprint 26. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
ores.telemetry meets the Component Clean Standard: the items marked All and Protocol pass, each item that does not apply is recorded with its reason, and ores.telemetry joins COMPONENTS_UNDER_TEST. Order 14 of 35 in the sprint 26 component clean-up, tier 2 (higher infrastructure).
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 26 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-09-26 |
| End | 2026-09-26 |
3. Acceptance
- Every checklist item that applies to a component of kind Protocol passes, with its evidence recorded on the task.
- Every item that does not apply is recorded as not applicable, with the reason.
- Every generator defect found is fixed at its source, with a regression test.
- ores.telemetry is listed in
COMPONENTS_UNDER_TEST, andcheck_component_drift.py --allpasses.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Bring ores.telemetry to the clean standard | DONE | 2026-09-26 | 2026-09-26 | Work ores.telemetry through the Component Clean Standard in order and record each item. |
5. Notes
- Survey on 2026-09-23: 0 entity, junction or operation models; 89 C++ files outside tests, 0 of them generated (0%); 5 messaging headers, 5 of them hand-written.
- Has SQL and hand-written protocol headers but no models: its wire types need models (M06, P04).
6. Decisions
- A Protocol component models its messages, not its tables. The survey found five SQL tables, a repository and a service, and no model at all. Modelling the tables would have moved this story into the Entity items the sprint did not scope it for, so the three message surfaces are modelled and the tables stay hand-written. The repository reads the generated payload types, which is the consequence: the wire payload is where the type lives.
- A test is not a consumer. B06 found the distributed-tracing API reached only from tests and four stats reads in the same position. Both are kept, and each has a capture naming the consumer that should reach it, rather than being deleted out from under a working aggregation.
- An unreached read behind a live subject is a defect, not dead code. The two NATS sample handlers answered every request with an empty sample list while the repository reads that answer it sat unreached. The handlers call them now.
- Correct a wrong claim in a documentation header rather than delete the header. Three namespace headers named the wrong namespace, the wrong module or an exporter this task deletes. All three are kept and corrected.
7. Out of scope
- The stats surface. The four reads and their SQL functions compute the statistics, and nothing can ask for them until a subject and its models exist. Recorded as the `expose_the_telemetry_stats_surface` capture.
- The distributed-tracing API. It is complete and tested and no component calls it yet. Recorded as the `instrument_components_with_telemetry_context` capture.
- Generating the messaging registrar. The component's registrar stays hand-written; the `codegen_messaging_registrars` capture owns that change.
- The five tables and their RLS policies, which the Protocol scope leaves hand-written.