Provider Chat Smoke

This skill adds provider-chat gates on top of interactive-testing. Launch, drive, screenshot, and tear down exactly as that skill describes, using a managed --mode real session for live gates. Keep the work in the disposable fixture project, never approve a write, and delete the smoke session directory when the run finishes. Copy cited screenshots and reports into tmp/ first.

Plan

1. From the diff and the integration smoke plan, list every provider and presentation surface in scope. For provider additions and updates, complete native steering qualification before choosing or retaining interrupt-and-resend. Derive other applicable gates from the provider integration lessons.
2. Split gates into live (an authenticated provider and its real server) and deterministic (mock/unit coverage for protocol branches that cannot be driven safely against an external provider).
3. Use a fresh thread per provider and short marker prompts (e.g. QWEN_SMOKE_OK); never use prompts that change the repository.
4. Capture screenshots, runtime items, final thread state, and the first three console/runtime errors. The suite is not successful while a required gate is unresolved.

Native Steering Qualification

Required for every provider addition and version/capability update, including an existing adapter with no native steering wired. This is the shared qualification gate for add-provider and supported-version-update; keep its detailed steering procedure here rather than duplicating it.

1. Trace the current path. Record the exact executable/runtime version and execution target (native, WSL, profile, or cloud). Trace a GUI submit while working through the authoritative supervisor session: does it use steerTurn / ACP promptSteering, or cancel-and-resend? A queue UI, hidden steerContext, a stale probe cache, or the absence of an adapter method does not prove native user steering support or lack of support.
2. Check current and newer contracts. Inspect the provider's current documentation/source and actual SDK or negotiated protocol payloads; record the exact capability location, request method/metadata, and response lifecycle. When authorized, check current supported release notes for native steering introduced after the installed version. Qualify a newer candidate in an isolated fixture, never silently update the user's CLI/profile or restart active work. Do not infer a capability from a guessed RPC name, flag, version number, or one failed probe. If access or evidence is missing, mark it unverified rather than unsupported.
3. Prefer qualified native delivery. If supported, use an existing steerTurn seam or provider-owned ACP promptSteering declaration; prefer runtime capability negotiation over a hard-coded version check. Keep vendor keys/parsers inside the provider folder. Preserve compatible behavior for older/missing/malformed capability responses. Interrupt-and-resend is a fallback only after documenting why the tested version cannot use native steering; do not treat an old fallback as permanent when a newer supported version can avoid cancellation.
4. Prove preservation during real work. In a fresh managed fixture thread, start a harmless long-running subagent using a profile that actually has the required execution tools. Wait for an actual running child tool/runtime item and record its identity; do not match words in a command catalog or count a steer sent before the original prompt or after completion. Send a marker through the real composer while that child runs. Native delivery must apply the marker without session/cancel, process/session replacement, or child cancellation/relaunch, and the same child must finish successfully. If the provider has no subagent surface, document that with evidence and still prove an in-flight native steer; do not invent support.
5. Keep Stop and accounting separate. Exercise explicit Stop during actual activity and prove it cancels; normal completion before the click is not a pass. Qualify repeated steers, rejected/racing requests, and non-text/attachment behavior without silently dropping or duplicating input. Capture whether accepted prompt replies repeat usage for one native turn; repeated consumption samples must not be counted twice, and genuinely separate samples must remain separate.
6. Lock the contract down. Add deterministic tests for qualified native delivery without cancel when supported, the old/absent/malformed handshake fallback, same-child preservation where applicable, rejected/racing steer delivery, explicit Stop with no replay, and usage identity/fallback when replies repeat usage. Report the tested version(s), capability snapshot, actual steering path, live evidence, newer-version findings, and any fallback limitations. Separate verified-native, evidence-backed unsupported-at-version, and blocked/unverified outcomes; a skipped native check is never a pass.

Live chat matrix

Run each applicable row for every requested provider through the real UI. If a provider finishes before a timing-sensitive control can be used, retry with a longer harmless response.

A response that ends before the Stop click leaves Stop untested; do not count a normal completion instead. When a provider's capabilities do not expose questions, permissions, or model changes, report those gates as not applicable with the advertised capability snapshot rather than claiming support.

ACP connection analysis

For a real ACP provider, prove the path, not just the rendered reply:

1. Record availability/authentication and the probed capabilities: models, modes, effort tiers, approval policies, slash commands, presentation modes.
2. createStructuredSession() succeeds and session/new or session/load yields a stable session reference. For providers that discover their session id after launch (example: Kimi's delayed session-file discovery), verify the discovered providerSessionId is persisted.
3. session/update messages produce the expected canonical runtime items: user message, reasoning, assistant message, tool call, and tool/command result.
4. Each blocking request gets exactly one request.resolved outcome: answered, declined, or cancelled.
5. A model change reached the live ACP session config, not just the picker: the persisted thread config changed and the next turn uses it.
6. Reopening does not duplicate Poracode's persisted chat items with replayed ACP history.

Capture session identity and configs without copying credentials, bearer tokens, or sensitive environment values into artifacts.

Deterministic ACP branch matrix

Cover each branch with focused tests or mocks when the live provider cannot safely expose it, and keep a production scenario mapping for any new provider surface.

Classifying live failures

Some rejections come from the provider's own routing, not Poracode. Classify before writing a verdict:

• Route rejects media in history (example message: provider-private history is incompatible with the active route: retained media history is unsupported): Poracode delivered an image the route cannot take. Fix delivery (path mention plus readsImageAttachmentsFromHost: false), not error handling.
• Session already in use (sessionInUse): another live host holds the provider-side session lock, typically an orphaned WSL host that teardown missed. Poracode must surface this as a turn error, never hang.
• Slow resume vs hang: a large session resuming slowly still streams runtime records; a hang is "working" with no item activity and no records.

Report

Give a verdict per provider and per gate: PASS, FAIL, SKIPPED, or NOT APPLICABLE, with connection/capability evidence, session-reference continuity, error count with the first three errors, and screenshot/report paths under tmp/. Keep real provider evidence separate from mocked protocol coverage.

For providers whose server runs in WSL, teardown hygiene is part of the verdict: after stopping a thread and after stopping the app, check the distro for surviving provider processes (ps aux | grep <binary>); a survivor holds provider-side locks and breaks the next resume.