Example-readiness: bridge cA2A to a runnable example (offline now, live peer path next)

[imran-siddique]

Goal

Give cA2A a runnable example story comparable to the cMCP examples (where you start a gateway, run an agent, and get a signed record). This issue captures the gap and a staged bridge plan.

Where cA2A is today (ground truth)

ca2a-runtime v0.1.0 (Alpha). The CLI exposes only validate-config and verify-chain — there is no start, no server, and no transport code (no uvicorn/fastapi/http/jsonrpc/socket anywhere in src/). The enforcement core (peer.py: handle_peer_request / enforce_peer_call) is implemented but transport-agnostic and unwired; its docstring notes a transport must parse the A2A wire into a PeerRequest and call it, and that transport does not exist yet.

Primitive status:

• Attenuated delegation — implemented, offline-verifiable (ca2a verify-chain).
• Peer runtime attestation — verifier-only, synthetic vectors; no live handshake; no GPU-CC.
• Sealed peer channel — crypto implemented, but not bound to a verified measurement on a live call.
• Provenance DAG — implemented offline (provenance.verify_dag, cross_check_chain), not TRACE-signed, and not exposed in the CLI.

What a full end-to-end example needs (ranked gap)

1. A2A transport adapter + ca2a start — HTTP/JSON-RPC server mapping A2A messages to PeerRequest. The single keystone; pure integration on the ready decision core. (Tier 2/3)
2. Live attestation handshake + seal-to-verified-measurement wiring on a call.
3. One real hardware backend (SEV-SNP/TDX/TPM quote generation) so at least one path verifies a genuine quote end to end. Required before any "attested across trust domains" claim. Shared with cmcp (SPEC/ROADMAP say cA2A reuses cmcp's TEE + policy primitives).
4. Signed TRACE record emission + a ca2a verify to match cmcp's signed RuntimeClaim.

Bridge plan

Now (no new runtime work): ship an honest offline example that productizes experiments/claim6-cross-operator-attestation/run.py into example shape (README + config + Cedar policy + demo.py): Parent issues an attenuated chain, Child scope ∩ Cedar policy, task sealed to Child's attested key, per-hop provenance records, offline chain+DAG verification, binary-swap rejection. Label clearly that attestation is software-asserted (synthetic vectors) and only chain + DAG verification are hardware-independent. Add a ca2a verify-dag CLI command so the DAG verifier is reachable like verify-chain.

Then: items 1 → 2 → 3/4 above, tracking the shared hardware-attestation backend with cmcp.

Deliverables tracked here

• ca2a verify-dag CLI command (expose provenance.verify_dag + cross_check_chain)
• examples/cross-operator-delegation/ offline example (productized claim6) with honest dev-mode labeling
• A2A transport adapter + ca2a start (Tier 2)
• Live attestation handshake + seal binding (Tier 2)
• One real HW attestation backend, shared with cmcp (Tier 3)
• Signed TRACE emission + ca2a verify (Tier 2)

[imran-siddique]

Closing as superseded. The immediate deliverables here — the ca2a verify-dag CLI and the offline cross-operator delegation example — shipped in #44. The remaining checkboxes (live A2A transport + ca2a start, live attestation handshake, hardware backend, signed TRACE emission) are now tracked on the path-to-0.1.0 tracker #47. No separate action needed on this issue.