Is your feature request related to a problem? Please describe.
Yes. Several issues make the current CLI harder to use than it needs to be:
- Overlapping commands:
ado show details and ado show summary both expose aggregate information about discovery spaces in overlapping ways (show summary already embeds the same kind of space statistics that show details prints, while show details also prints related resources). For operations, only show details exists—there is no parallel “summary” path—so the mental model is inconsistent across resource types.
- Confusing naming and scope: Commands like
show details, show summary, show entities, show requests, and show results mix “overview,” “tabular measurement/trace data,” and “entity measurement tables” in ways that are easy to confuse. Names like “entities” vs what the command actually outputs (measurement data / timeseries-style tables), and “details” vs “summary,” do not clearly signal what you get or how long it will take.
- No bulk overview for stats: You cannot easily get the same kind of aggregate stats for many spaces or operations in one go.
ado show summary supports multiple space IDs and label/query filters, but ado show details does not, and operation overviews are effectively single-resource only—so comparing or auditing many resources is awkward compared to ado get, which already supports listing and filtering.
Describe the solution you'd like
1. ado show stats
Introduce ado show stats as the single command for aggregate, computed statistics about discovery spaces and operations—analogous in ergonomics to ado get (filter by labels or field queries, pass multiple IDs, optional --use-latest), but returning stats views that may be more expensive to compute than plain resource retrieval.
- Resource kinds:
space and operation.
- Selection model (like
ado get): multiple explicit IDs, and/or --label / -l and/or --query / -q to select resources.
- Output: Table / CSV / markdown (and existing summary-style formats) for comparing many resources in one run.
- Separation of concerns: This command should not duplicate
ado show related; relationship lists and future tree/deps views stay on ado show related. ado show details / ado show summary can be deprecated or aliased to show stats over time.
2. Merge ado show requests and ado show results into ado show trace (or some other name)
Replace the split between request-level and result-level tables with a single command (e.g. ado show trace) that exposes measurement request/result metadata timeseries views . Support operation and discoveryspace scopes: for a space, aggregate traces across operations that used that space. Use flags such as --requests / --results to select which projection to print, and fold in ado get measurement_request-style single-request inspection where it makes sense (e.g. by request ID).
3. Rename ado show entities → ado show data
Rename the command to data because it surfaces collected (or potential) measurement data in tabular/CSV/JSON form—“data” is clearer than “entities” for most users. Keep entities as a deprecated alias for a transition period.
Describe alternatives you've considered
- Keep
show details and show summary separate: Avoids migration, but preserves overlap and inconsistent space vs operation behavior.
- Only extend
ado get with --stats: Reuses one verb but mixes cheap resource retrieval with heavier aggregations and may confuse defaults and help text.
- Top-level
ado stats / ado trace / ado data instead of ado show …: Flatter CLI, but more root commands; nesting under show groups “views over project data” separately from get (stored resources) and describe (full resource docs).
- Leave requests/results as two commands: Clearer names for each narrow action, but duplicates setup, help text, and user navigation for what is effectively one “measurement trace” workflow. Also show results is in particular misleading
Additional context
This should be considered along with #736 - c.f. the --stat command proposed there
Is your feature request related to a problem? Please describe.
Yes. Several issues make the current CLI harder to use than it needs to be:
ado show detailsandado show summaryboth expose aggregate information about discovery spaces in overlapping ways (show summaryalready embeds the same kind of space statistics thatshow detailsprints, whileshow detailsalso prints related resources). For operations, onlyshow detailsexists—there is no parallel “summary” path—so the mental model is inconsistent across resource types.show details,show summary,show entities,show requests, andshow resultsmix “overview,” “tabular measurement/trace data,” and “entity measurement tables” in ways that are easy to confuse. Names like “entities” vs what the command actually outputs (measurement data / timeseries-style tables), and “details” vs “summary,” do not clearly signal what you get or how long it will take.ado show summarysupports multiple space IDs and label/query filters, butado show detailsdoes not, and operation overviews are effectively single-resource only—so comparing or auditing many resources is awkward compared toado get, which already supports listing and filtering.Describe the solution you'd like
1.
ado show statsIntroduce
ado show statsas the single command for aggregate, computed statistics about discovery spaces and operations—analogous in ergonomics toado get(filter by labels or field queries, pass multiple IDs, optional--use-latest), but returning stats views that may be more expensive to compute than plain resource retrieval.spaceandoperation.ado get): multiple explicit IDs, and/or--label/-land/or--query/-qto select resources.ado show related; relationship lists and future tree/deps views stay onado show related.ado show details/ado show summarycan be deprecated or aliased toshow statsover time.2. Merge
ado show requestsandado show resultsintoado show trace(or some other name)Replace the split between request-level and result-level tables with a single command (e.g.
ado show trace) that exposes measurement request/result metadata timeseries views . Supportoperationanddiscoveryspacescopes: for a space, aggregate traces across operations that used that space. Use flags such as--requests/--resultsto select which projection to print, and fold inado get measurement_request-style single-request inspection where it makes sense (e.g. by request ID).3. Rename
ado show entities→ado show dataRename the command to
databecause it surfaces collected (or potential) measurement data in tabular/CSV/JSON form—“data” is clearer than “entities” for most users. Keepentitiesas a deprecated alias for a transition period.Describe alternatives you've considered
show detailsandshow summaryseparate: Avoids migration, but preserves overlap and inconsistent space vs operation behavior.ado getwith--stats: Reuses one verb but mixes cheap resource retrieval with heavier aggregations and may confuse defaults and help text.ado stats/ado trace/ado datainstead ofado show …: Flatter CLI, but more root commands; nesting undershowgroups “views over project data” separately fromget(stored resources) anddescribe(full resource docs).Additional context
This should be considered along with #736 - c.f. the --stat command proposed there