comply() ComplianceResult drops step.error to {} — wire-level INVALID_REQUEST detail lost

[bokelley]

Summary

When a comply() scenario step fails, ComplianceResult.tracks[].scenarios[].steps[].error ships as {} even though the underlying SDK transport has the full structured error (adcp_error: { code, message, recovery, field, details.validation_errors }).

Repro

Run any create_media_buy-touching storyboard against a 3.0-strict seller that rejects the runner's request. Compare:

SingleAgentClient.executeTask (returns the full error):

{
  "status": "failed",
  "error": "INVALID_REQUEST: create_media_buy failed: Invalid value for field 'packages.0.product_id': Field required",
  "data": {
    "adcp_error": {
      "code": "INVALID_REQUEST",
      "message": "create_media_buy failed: ...",
      "field": "packages.0.product_id",
      "details": { "validation_errors": [...] }
    }
  }
}

comply() ComplianceResult for the same call:

{
  "step_id": "...",
  "task": "create_media_buy",
  "passed": false,
  "error": {}                              ← detail dropped
}

The comply harness is collapsing/normalizing the result and stripping the meaningful payload.

Why it matters

The comply harness output is the canonical input for AAO heartbeat grading. With error: {}, an owner staring at a failing storyboard from the dashboard cannot see what their agent actually returned wrong on the wire. Diagnosing the failure requires re-running with a different tool. This is the main reason it took several probes to discover #1676 and #1677 even though both errors were sitting on the wire all along.

Fix

Preserve the underlying transport error on every step entry. Minimum:

step.error = transportResult.error ?? {};
// or, more usefully, an object with at minimum:
step.error = {
  message: transportResult.error?.message,
  code: transportResult.error?.code,
  adcp_error: transportResult.data?.adcp_error,
};

Add a serialization test that pins this contract — step.error must be JSON-serializable and must carry the underlying error message when the step failed for a non-skip reason.

Cross-link

Same Wonderstruck probe as #1676–#1678. Findings doc in adcontextprotocol/adcp .context/wonderstruck-findings.md.

[bokelley]

Triage

Classification: Bug
Bucket(s): conformance, library
Status: drafting-pr
Milestone: (omitted — no target version named)

What the experts said:

• code-reviewer: root cause confirmed at task-map.ts line 144 — adcpError never forwarded; fix is additive adcp_error field; also flagged missing delete step.adcp_error on peer_branch_taken regrade (fixed before PR)
• dx-expert: structured error dropout (Bug A) and possible {} runtime type violation (Bug B); Option C — keep error: string, add parallel adcp_error: AdcpErrorInfo — is the right shape for both human and LLM consumers; fix_command + validation alone insufficient when the task itself fails before any validation runs
• ad-tech-protocol-expert: spec-aligned, AdcpErrorInfo is the canonical error shape, minor bump correct, expect_error suppression is defensible and consistent with existing error gate

My take: Draft PR #1684 adds adcp_error?: AdcpErrorInfo as a parallel field through the full pipeline (TaskResult → StoryboardStepResult → ComplianceFailure), keeping error: string unchanged. All changes are additive; no existing callers break.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_018694zhanVSMB72JRJEQCwq

---

Generated by Claude Code

[bokelley]

Folding this into the coordinated stance at #1685. This is hat 4 of 5 — the keystone.

Lands first. While step.error is {}, the other four hats can regress silently because every failure looks identical from the grader. Once adcp_error flows through (PR #1684), the other four PRs (#1683/#1681/#1682 and the pending #1678 PR) become observable in cert runs and any future politeness regression becomes a tripwire.