appId: cc.agentlabs.opencode
name: Variant picker - reasoning-effort chip renders, selects, and still sends
---
# New-feature regression coverage for VariantPicker
# (src/components/chat/VariantPicker.tsx): the reasoning-effort chip only
# renders when the selected model's provider entry carries `variants`
# (src/stores/catalog.ts / GET /provider), selecting an option updates the
# chip label, and sending a message afterwards still works end-to-end
# (variant flows into sendMessage -> client.session.prompt's `variant` field
# — see src/stores/sessions.ts sendMessage).
#
# The CI job starts `node tests/fixtures/mock-opencode-server.ts --port 4099`
# on the runner host BEFORE this flow runs (same fresh, non-seeded normal-mode
# server used by directory-picker.yaml — GET /provider's mock-model carries
# low/medium/high variants; see tests/fixtures/mock-opencode-server.ts).
#
# A brand-new session has NO explicit model selection: src/lib/model-selection.ts
# chooseModelSelection() deliberately returns null until the user picks one
# (issue #37/#35 — the provider registry's "default" model is unreliable), so
# app/session/[id].tsx's currentModelVariants is undefined and the chip does
# NOT render on session open. This flow explicitly opens the model picker and
# selects the mock provider's model first, which is what actually makes
# variants available — matching how a real user reaches this chip.
#
# This flow does NOT assert on the SSE-streamed assistant reply after
# sending — see the "Sending a message" comment near chat-send-button below,
# and activation-positive.yaml's file-level comment, for why (issue #90 mode
# B: a CI-harness-specific SSE limitation, not an app bug).

- launchApp:
    clearState: true
- assertVisible:
    id: "telemetry-consent-card"
- tapOn:
    id: "telemetry-decline-button"

- assertVisible:
    text: "No Connection"
- tapOn:
    id: "add-connection-button"
- tapOn:
    id: "connect-ip-input"
- inputText: "127.0.0.1:4099"
- hideKeyboard
- tapOn:
    id: "connect-submit-button"

# 40s margin: see activation-positive.yaml — the connect handshake's own
# fetches are individually capped at 30s (src/lib/sdk.ts REQUEST_TIMEOUT_MS).
- extendedWaitUntil:
    visible:
      id: "connection-status-dot"
    timeout: 40000
- takeScreenshot: variant-S1_connected

- tapOn:
    id: "new-session-fab"
- extendedWaitUntil:
    visible:
      id: "chat-message-input"
    timeout: 15000

# Explicitly pick the mock provider's model — a fresh session has no model
# selection yet (see comment above), so the variant chip has nothing to key
# off of until this happens.
- tapOn:
    id: "model-chip"
- extendedWaitUntil:
    visible:
      id: "model-option-mock-mock-model"
    timeout: 10000
- tapOn:
    id: "model-option-mock-mock-model"

# The chip only appears once catalog.load() (triggered on connect, see
# app/_layout.tsx) has resolved GET /provider and found variants for the
# selected model — wait rather than assert immediately.
- extendedWaitUntil:
    visible:
      id: "variant-chip"
    timeout: 15000
- assertVisible:
    text: "Auto"
- takeScreenshot: variant-S2_chip_default_auto

- tapOn:
    id: "variant-chip"
- assertVisible:
    text: "Reasoning Effort"
- assertVisible:
    id: "variant-option-low"
- assertVisible:
    id: "variant-option-medium"
- assertVisible:
    id: "variant-option-high"
- takeScreenshot: variant-S3_picker_options

- tapOn:
    id: "variant-option-high"
# Sheet closes and the chip label reflects the new selection.
- assertVisible:
    text: "High"
- takeScreenshot: variant-S4_chip_shows_high

# Sending a message must still work with a variant selected (regression: the
# variant chip must not break the send path). Like activation-positive.yaml,
# this stops at the optimistic local echo (src/stores/sessions.ts) instead of
# waiting on the SSE-streamed assistant reply — issue #90 mode B (see
# activation-positive.yaml's file-level comment) proved that in THIS harness
# (Android emulator + this Node mock + adb-reverse) the long-lived SSE
# connection reliably delivers only its first chunk, so the reply never
# renders here regardless of app correctness. Asserting on it would be
# asserting on a CI-harness limitation, not real app behavior.
- tapOn:
    id: "chat-message-input"
- inputText: "Message with reasoning effort set to high"
- hideKeyboard
- takeScreenshot: variant-S5_message_typed
- tapOn:
    id: "chat-send-button"

- extendedWaitUntil:
    visible:
      id: "chat-bubble-user"
    timeout: 5000
- assertVisible:
    id: "chat-bubble-user"
- assertVisible:
    text: "Message with reasoning effort set to high"
# The chip must still read "High" after sending (selection persists across a
# send, it isn't reset once the message is submitted).
- assertVisible:
    text: "High"
- takeScreenshot: variant-S6_message_sent_variant_still_high