telemetry: record harness identity and forge pointers on the root run span

[rh-hemartin]

What happens

A fullsend run writes Level 1 telemetry as run-telemetry.jsonl (ADR 0050). The root run span records agent name, work item id, security trace id, gen_ai fields, exit code, and cost/turn aggregates.

It does not record which resolved harness produced the run, or which forge/CI identity the run was against (repo, SHA, change id, pipeline run). Downstream scoring and eval wrappers that need those facts scrape ambient CI env, which is unstable across local runs, child dispatches, and forges.

#5524 proposed a sibling harness-snapshot.json plus mirrored root-span attributes. That ADR was not accepted. Review settled on this split: primary run facts belong on the trace; extra on-disk files are for derived products (for example eval-measurements.jsonl from ADR 0087). Snapshot implementation was #5449 (closed, not planned).

What should happen

Harness fingerprint and forge/CI pointers are attributes on the root run span. They then appear in run-telemetry.jsonl with no extra file, and in OTLP when Level 2 export is on.

The set should be enough to answer "what harness/config produced this run, and against which forge/CI identity?" without scraping CI env. This issue covers both the harness content SHA tracked in #2368 and the forge/CI pointers. Close #2368 as overlapping when this lands.

When OTEL_SDK_DISABLED=true, Level 1 is not written; these facts are absent in that mode. A dedicated snapshot file is out of scope until the root-span attributes are shown not to be enough.

Context

Successor to closed #5524 (ascerra review, follow-up comment): start with root-span attributes, then reassess.

Related:

• #2368 (harness content SHA; overlapping, close when this lands)
• #5449 (closed snapshot tracker)
• operational observability
• Fullsend owns Level 1 / OTEL attribute names; external tools (including ABEvalFlow) map from that

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 10:16 AM UTC · Completed 10:21 AM UTC

Commit: a676e73 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $0.87

[fullsend-ai-triage]

Related work:

• feat: add fullsend.harness.content_sha trace attribute for config change correlation #2368 (harness content SHA) — overlapping, to be closed when this lands per issue description
• PR docs(adr): accept ADR 0090 harness snapshot for agent traces #5524 (ADR 0090 snapshot approach) — closed; review settled on root-span-only attributes
• Implement ADR 0071: harness-snapshot.json + root-span forge pointers #5449 (snapshot implementation) — closed, not planned

Proposed test case:

// Verify root span includes harness identity and forge pointers
// Setup: resolve a harness config, set forge identity (repo, SHA, change id)
// Action: execute a run with telemetry enabled
// Assert:
//   - root span has fullsend.harness.content_sha (non-empty hex)
//   - root span has forge repo, commit SHA, change/PR id attributes
//   - root span has CI pipeline run id when in CI
//   - attributes are absent (not empty) when not applicable
//   - OTEL_SDK_DISABLED=true: no telemetry file (existing behavior)

Implementation notes: The harness resolution code already computes the content SHA and the forge identity is available from the forge client. The main work is threading these values to the root span setup and choosing attribute names consistent with OTEL GenAI semantic conventions and the existing fullsend.* namespace.

---

Labels: Feature request adding telemetry attributes to the harness/runner telemetry subsystem, medium priority given downstream eval/scoring impact.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance