UX1 — Onboarding + pulse-design interview flow storyboard (E5)

[jack-champagne]

Part of the seam UX-prototype track (Krishna interview). Sequencing: basics — do first, alongside UX2.

What

A flow/content storyboard of the onboarding + pulse-design interview: system setup (platform / hamiltonian / config) and pulse design (initiate interview → decision tree → a tagged pulse). It is NOT a bespoke chat renderer.

⚠️ Renders via AskUserQuestion in v1 — this is a storyboard, not a chat UI

The interview-UX spec (spec-20260614-231647-amicode-interview-ux, armonissima) locked Claude-Code-first rendering (AskUserQuestion); Amicode becomes a richer renderer later. So this prototype exists to get feedback on what questions, in what order, with what defaults — every frame labeled "rendered by AskUserQuestion in v1." Do not build it as a production chat surface; that would quietly relitigate a settled decision.

Krishna's signal (interview 2026-06-30, p3 + p5)

• "onboarding — less scary when there's persistent data"; "interviewing on what the user wants to keep track of"
• system setup = platform / hamiltonian / config; pulse design = initiate interview → decision tree
• his open TODO: talk to experimentalists about what they change in config files (feeds the lab.toml schema)

Seam-prototype approach

Static/clickable storyboard frames in media/, behind a contract test. No question-tree renderer, no backend.

Feedback questions for Krishna / Andrew

1. Is the question set + order right for a real setup? What's missing, what's patronizing?
2. What do you actually want persisted out of onboarding (the "keep track of" list)?

Lanes

• Kate — storyboard frames (media/)
• Raghav — minimal webview shell + contract test
• Jack — the question-tree content/order

Refs: spec-20260614-231647-amicode-interview-ux, spec-20260529-amicode-architecture (armonissima). Source: Krishna UX interview note (pending promotion to armonissima).

[kateebonner]

UX1 content decision (design lane): rather than waiting on the question-tree content or reusing the atoms solve tree (which the interview note says is explicitly not Krishna's concern), I'm drafting the onboarding + pulse-design question tree as a strawman — grounded in his signals (platform / hamiltonian / config, "what do you want to keep track of?") and the lab.toml schema — for Jack to correct. A wrong-but-concrete strawman is the fastest way to get specific feedback on the issue's question 1.

Note for the schema loop: lab.toml v1 is transmon-only, so an onboarding tree that opens with "which platform?" outgrows it on question one. The strawman doubles as the lab.toml v2 field proposal, which is also the vehicle for closing Krishna's open TODO (what experimentalists actually change in config files).

Storyboard frames follow browser-first in media/, same operating model as #47, every frame labeled "rendered by AskUserQuestion in v1" per the warning above.

[kateebonner]

candidates for the interview/onboarding flow:

• Solver disclosure tier — integrator, backend, solver options, objective weights (Q/R) as a collapsed section; the glance tier stays quality metrics only, and the script remains the full truth (script_path is already recorded in run.toml).
• Data gap to close first — the most-swept knobs (Q, R, backend, integrator, tolerances) aren't recorded in result.toml; needs a params.solver sub-table in the solve template (same schema-safe pattern as params.gate/params.system). Matters more post-MadNLP/Altissimo when the backend stops being constant.
• Sweep digest — user tags (shipping with the UX2 card) cover manual differentiation today; the structural answer is the compare view (UX5 / UX5 — Instance-vs-historical compare view (E3) #51).
• Metrics conventions still owed a domain-owner pass — smoothness definition, robustness recording, spectral-bandwidth threshold (all rendered as proposed/dashed on the card until decided).