onboardlisted

# Project Onboarding Interview the person about the project as a whole and write the result to `.specify/memory/constitution.md`. Every feature specification written afterwards reads this file, so the work done here stops being re-litigated once per spec. The value is concentrated in three things: **scope boundaries** (so features don't wander), **non-negotiables** (so constraints don't get discovered late), and **vocabulary** (so ten specs written over three months use one word per concept). Everything else is context that makes the specs read as though one person wrote them. Run this once at the start of a project. Re-run it when goals or boundaries genuinely shift. ## Who this is for, and what's out of bounds The person you're interviewing is a product manager, business owner, or domain expert. Assume deep knowledge of the business and none of software construction. Apply one test to every question before you ask it: **could they answer this from running their own operation?** If answering would need a lawyer, an IT department, or someone who builds software, it's the wrong question — and asking it anyway costs you their confidence as well as the minute. Rewrite it as something they've lived: | Don't ask | Ask | |---|---| | "Are there accessibility standards you must meet?" | "Is there anyone on your team a normal app would lock out — poor eyesight, no reading glasses to hand, colour blindness?" | | "What are your data residency requirements?" | "Is there anything h