Pasqal device path — optimized pulse to a Pasqal Cloud device through the Pasqal Connection

[kateebonner]

Important

Problem

The Pasqal connectivity spike proves the full pipeline end-to-end (auth → Piccolo→Pulser translation → cloud submission → results) but lives on an unmerged branch, driven by a hand-run harness whose credential protocol has the agent set the password on its own command line. There is no product flow from an optimized pulse to a Pasqal device.

Approach

Land the spike, then wire it behind the Pasqal Connection as an agent-driven flow through the amico-pasqal launcher (chat verbs; the panel supplies connection state): credentials come from the store via the launcher (env-injected, off the transcript), the device list comes from the connection's persisted device metadata, and submission becomes a first-class flow from a run/catalog pulse to a chosen Device.

Approaches Considered

• Behind the Connection via the launcher (chosen) — reuses the panel's store/validation; secrets never re-enter chat.
• Keep the harness flow — rejected: password on a ps-visible bash line inside a persisted transcript.
• Julia-native Pasqal client — rejected for now: the Python SDK path is proven by the spike; re-platforming buys nothing yet.

Scope

• In: merging the spike (translation contract + tests + demos); the launcher integration; device selection; submit + result retrieval surfaced in product; free-emulator first.
• Out: real-QPU job management/queueing beyond submission; new credential UI (the Connections panel owns it); atom-position optimization productization (demos stay demos).

Assumptions / Open Qs

• Depends on the Connections panel (Pasqal card + store + launcher).
• Free-emulator remains the default target; paid/QPU targets need an explicit device choice each time.

---

Acceptance Criteria

1. With Pasqal connected, a user can pick a pulse (from a run or the catalog), pick a Device from the connection's persisted device metadata (the panel's status contract, refreshed on revalidation), submit, and see results — without touching env vars or the harness.
2. The spike's pulse-translation contract tests pass on the default branch.
3. The connector authenticates via the SDK's token provider using the stored token, delivered only through the launcher's env injection; the agent's command lines and transcripts stay secret-free, and no password exists anywhere in the flow (asserted by test).
4. A disconnected Connection, an expired token, and an empty-or-stale device list each disable the device path with a distinct, actionable message (reconnect / revalidate), never a silent failure.
5. Submitting to any non-free target (real QPU or paid emulator) requires an explicit per-submission confirmation of a submission digest — an authorization error is not a substitute for asking, and there is no automatic fallback to a paid target.

Key Decisions

• The Python SDK path (per the spike) stays the transport; the launcher owns the env boundary.
• Device selection is per-submission (a Device is reached through the Connection; it is never the credential owner — per the repo glossary's Connection/Device definitions).
• The spike's hardware gate carries forward as mandatory: digest + explicit "yes, submit to " confirmation before any non-free submission.

Source

• The Pasqal connectivity spike branch (milestones 1–2, pulse contract, E2E submission, demos)
• ADR 0001/0002 · the Connections-panel issue (dependency) · the repo glossary (Connection / Device)

[kateebonner]

Depends on #159 (Pasqal card + store + amico-pasqal launcher). Spike branch: kate/pasqal-cloud-connectivity.

[kateebonner]

Unblocked by #169 (merged): read the stored token via the credential store (readCredential('pasqal-cloud')); the device list persists in connection-status metadata (refreshed per (re)validation); launch through amico-pasqal (#168 — env contract PASQAL_TOKEN + PASQAL_PROJECT_ID, connector wraps it in a token provider). Live token-mode probing + real device-state enrichment deliberately left to this issue.