Expose skill telemetry availability in reports

[V3RON]

detectedSkills can be empty for two different reasons: the runner observed skill telemetry and found no skills, or the runner could not provide reliable telemetry for that run. Consumers currently have no machine-readable way to distinguish those cases.

Observed Findings

• SessionReport includes detectedSkills, but no telemetry capability or availability field.
• Documentation notes that not every runner exposes skill loads explicitly.
• Assertions and dashboards must infer telemetry availability from an empty array, which is ambiguous.
• Some runners may only expose related evidence, such as file reads or related skills, rather than explicit skill-load signals.

Suggested Behavior

Add a machine-readable field such as telemetryAvailable: boolean or a richer telemetry capability descriptor to SessionReport. The field should clarify whether explicit skill telemetry, inferred skill telemetry, or no skill telemetry is available for the runner/run.

Resolution Summary

After this issue is resolved, reports should make skill telemetry availability explicit so assertions, CI dashboards, and custom reporters can distinguish “no skill detected” from “telemetry unavailable.”

[V3RON]

Implementation Plan

Use a richer SessionReport field rather than a boolean, because current adapters mix explicit skill-load signals with inferred SKILL.md reads.

Proposed report shape:

skillTelemetry: {
  availability: "explicit" | "inferred" | "unavailable";
  sources: Array<"skill-signal" | "skill-file-read">;
}

Behavior:

• explicit: runner/run exposes direct skill-load events; empty detectedSkills means no explicit skill loads were observed.
• inferred: no direct skill-load telemetry, but SkillGym can infer skills from observed skill file reads; empty detectedSkills means no skill evidence was observed through reads.
• unavailable: runner/run cannot provide reliable explicit or inferred skill telemetry; empty detectedSkills must not be interpreted as “no skills”.

Adapter handling:

• OpenCode, Claude Code, and Cursor-style adapters should set explicit when they observe or support skill tool/signal extraction, with skill-signal as a source and optionally skill-file-read when read inference is also used.
• Codex-style adapters currently appear inference-only, so they should set inferred when file-read telemetry is available and unavailable if structured artifacts are missing or cannot expose reads reliably.
• Failure fallback reports should set unavailable, since they are synthetic reports rather than normalized runner telemetry.

Reporting/assertion behavior:

• Preserve detectedSkills as-is for compatibility.
• Include skillTelemetry in per-run report.json and aggregate results.json.
• Consider adding telemetry context to failed skill assertion messages when availability is unavailable or inferred, so CI failures explain whether absence is meaningful.
• Standard CLI output does not need a new column initially; machine-readable reports are the main resolution.

Tests:

• Add schema/helper coverage so generated reports always include skillTelemetry.
• Add adapter normalization tests for explicit, inferred-only, and unavailable/raw-artifact-missing cases.
• Add assertion failure-message coverage for empty detectedSkills with unavailable telemetry.
• Add serialization/regression coverage to ensure results.json and report.json retain the new field.

Rollout:

• Treat this as an additive API change.
• Export the new telemetry type alongside existing report types.
• Update session report docs to explain how consumers should interpret empty detectedSkills under each availability mode.
• No migration is required for existing reports, but consumers should handle the field as optional when reading historical artifacts.