visionlisted

# vision — what the product is, and what it refuses to become > Part of **super-ux** — see [system-map.md](references/system-map.md) for the > whole pipeline. After writing the document, run `python3 docs/ux/lint.py`. The layer above `ux-foundation`. Foundation answers **who** uses the product and **why**; vision answers **what the product is** and **what it refuses to become**. Without it, "should we build this?" has no answer that outlives the person who last had an opinion. Do not confuse it with `scenarios.md`, the other layer whose name starts with "what": scenarios say what the product **does**, step by step. A feature can be perfectly scenario'd and still violate the anti-vision. > **This skill produces two things, and the second is the point.** > 1. `docs/ux/vision.md` — the document. > 2. A **vision-alignment rule** in the project's own instruction file, so every > later feature gets checked against the vision instead of the vision being > written once and never read. > > A vision nothing reads is a document, not a constraint. Fits the chain: **vision → foundation (personas, JTBD, journeys, stories) → flows → scenarios → audit.** Each layer traces up to the one above it. ## Step 0 — read the project, not its README Before writing a word: 1. `README.md`, `ARCHITECTURE.md`, `ROADMAP.md`, `CHANGELOG.md`, everything in `docs/`. 2. Key source: entry points, main services, the schema, the routing table. 3. Marketing surfaces if they exist — landing, pricin