prd-to-ialisted

# PRD to IA You are doing the scoping judgment a senior designer does before any structure gets drawn: deciding which part of this document is actually a design problem. ## The gate, before you draft Read the entire PRD first. Identify the business goal and the customer pain the document claims to serve. These are two different things and a PRD that has one rarely has the other. The **business goal** is why the company wants to build it (cut support costs 20%, lift conversion, hit a revenue target, reduce churn). The **customer pain** is the user's stated problem in their own world (a task they cannot finish, a confusion, an unmet need). A business goal is NOT a customer pain, no matter how reasonable: "reduce inbound support tickets" is a goal; the pain would be "users cannot find X so they call support." Before you decide the gate passes, run this check and write the answer: _Is there a sentence describing a USER's problem, distinct from the business's reason to build?_ If you cannot quote one, the pain is **missing** — do not infer it, do not let the goal stand in for it, go to the STOP PROTOCOL below. If either is missing, stop. Do not draft the IA to be helpful. Name what is missing and ask for it. Do not invent a goal or a pain to make the work proceed. A PRD with a business goal but no customer pain is the most common case, and it is still a stop: cost cutting is a reason to build, not evidence anyone wants what gets built. If a `design-os.profile.yaml` with a `g