Authenticated SaaS Release Smoke Test

# Authenticated SaaS Release Smoke Test

Verify one critical read-only workflow in an authenticated SaaS application after a release, using a user-controlled TinyFish browser profile and recoverable evidence.

## Loadout capabilities

Use <action-tag>api:tinyfish_api:list_browser_context_profiles</action-tag> to find a suitable existing profile. With approval, use <action-tag>api:tinyfish_api:create_browser_context_profile</action-tag> and <action-tag>api:tinyfish_api:create_browser_context_profile_setup_session</action-tag> to open a protected user handoff for login, then use <action-tag>api:tinyfish_api:save_browser_context_profile_setup_session</action-tag> after authentication succeeds or <action-tag>api:tinyfish_api:cancel_browser_context_profile_setup_session</action-tag> if it is abandoned. Use <action-tag>api:tinyfish_api:run_async</action-tag> for the approved smoke test, <action-tag>api:tinyfish_api:get_run_by_id</action-tag> to poll and recover it, and <action-tag>api:tinyfish_api:get_step_screenshot</action-tag> only for a relevant verification step.

Read the current schemas before preparing calls. These browser Actions require the user's connected personal TinyFish credential. Verify the connection through Aident Vault. Never ask the user to paste passwords, one-time codes, magic links, cookies, storage state, session IDs, or browser endpoints into ordinary chat.

## Define one safe test

Collect the exact application URL, environment, release identifier, user role, expected starting page, one critical workflow, expected visible result, and forbidden actions. The workflow must be read-only or safely reversible and must fit one session. Examples include opening an existing dashboard, filtering a list, viewing an existing record, or confirming a non-sensitive setting is visible.

Do not use this Skill to create, edit, submit, delete, invite, publish, approve, purchase, rotate credentials, change access, or trigger production jobs. If the requested validation requires any of those actions, stop and ask for a different read-only acceptance check.

## Establish the authenticated profile

List profiles and show only non-sensitive names and IDs needed for selection. Ask the user to choose an existing profile or approve creation of one clearly named for the application and environment. Do not set it as the default unless the user explicitly requests that separate change.

When login is required, create a profile setup session at the exact application login URL and open the returned user-facing stream URL exactly as returned. Confirm the stream renders the intended page and state the remaining session window. Keep the session active while the user completes login, MFA, a human check, or a magic-link flow inside that same protected browser context.

Do not inspect or repeat entered secrets. Save the profile only after the application visibly confirms authentication. Cancel an abandoned or broken setup session rather than asking the user to refresh it repeatedly. Never disclose the setup URL after the handoff is complete.

## Review and run

Write a precise TinyFish goal that names the starting URL, selected profile, permitted navigation, expected visible assertions, forbidden controls, and stop condition. Use `use_profile: true` with the approved `profile_id`. Request screenshots or HTML only when required to prove the acceptance criteria.

Preflight the exact run. Show the profile name, target environment, goal, evidence capture, and quote, then wait for approval. Run once asynchronously and retain the returned run ID. Poll until TinyFish reports a terminal state; do not treat a client timeout as failure and do not start a replacement while the original run remains unresolved.

If the application asks for renewed authentication, elevated access, consent, or a state-changing action, stop the run at that boundary and report `Blocked`. If the final state is ambiguous, inspect the specific step screenshot rather than rerunning the whole workflow.

## Evidence and result

Mark the test `Pass` only when every approved visible assertion is observed in the intended environment and role. Mark it `Fail` for a reproducible assertion mismatch, `Blocked` for authentication or permission boundaries, and `Needs Review` for incomplete or ambiguous evidence. A terminal TinyFish run alone is not proof of product correctness.

Return the environment and release identifier, profile name, tested role, exact workflow, assertion results, furthest confirmed step, terminal provider state, run ID, and selected evidence. Redact personal or tenant-sensitive values. State explicitly that the workflow made no changes.