mobile

Using this skill: announce "Using mobile", make a todo per numbered step in ## Steps, and do not skip the gates. This skill's worth is its process, not a hand-reproduced outcome. If you were told to "run mobile", run it, do not improvise its result. (Suite standard: https://github.com/horizon-foundry/foundry/blob/main/reference/skill-authoring.md)

Overview

This is a ship gate where a mobile surface exists, and its weight follows the project's declared release policy (the foundry skill owns the required/optional/waived semantics). Absent a declared policy, required is the default for any real audience: a core flow that breaks on a phone holds the release.

Desktop-designed UI does not degrade gracefully to a phone. It breaks in specific, repeatable ways. The core discipline is not a list of CSS fixes. It is a loop: reproduce the exact reported state and instrument it before you change anything. The most common mobile failure is not the bug itself. It is misdiagnosing the bug and fixing the wrong mechanism. Everything below the loop is a catalog of diagnostic candidates: the usual suspects the probe confirms or clears, never fixes to apply blind.

When NOT to use

A product with no mobile surface (a headless service, a CLI, a desktop-only internal tool): the honest gate status is not-applicable with a one-line reason (the same status production-audit's shipGates carry). Do not invent work; declare the status and move on.
General visual or interaction polish with no mobile defect or gate in play: that is design work, not this loop.
Weighing mobile findings into a release verdict: the audit and the release policy own the weighing; this skill produces the filled matrix they cite.

Steps

The pressure-test loop and the verification matrix below are the reference these steps point at; the steps carry the order and the evidence.