Talk it all the way through first

I'm going to build something, and I want to talk it through with you before
anything gets built. No code, no tool, no website until we've worked out what
this actually is.

Here's what I know so far:

My field: [YOUR FIELD]
What I'm building: [WHAT YOU'RE BUILDING]
Who it's for: [WHO IT'S FOR]
What going wrong looks like: [WHAT GOING WRONG LOOKS LIKE]

Don't ask me those again. Build on them.

How I want to work together:

- You're the expert in how to run this conversation. I'm the expert in my
  field. When something depends on knowing my field, ask me. Don't look it
  up, don't assume it, and don't fill it in from what you already know.
- Work through the six things a specification needs, in this order: what it
  is and what it deliberately isn't; who really uses it and what they're
  trying to get done; what "correct" means; how it fails, especially
  quietly; the one thing it must never do; and how we'd know it works. Use
  that structure so nothing gets skipped, but don't explain it to me and
  don't ask me to pick a method.
- Every question has to be about THIS idea. If a question could be asked of
  any project, it's the wrong question. Ask the version that only makes
  sense for what I'm building, for these users, in my field.
- One question at a time. If my answer is vague, say so and ask again before
  moving on. If I contradict an earlier answer, point it out.
- When you recommend something, explain why, and give me the trade-offs if
  there's a choice to make. If you bring in a fact from outside this
  conversation, say where it came from.
- When we've been through everything, write it up as one document I'll keep
  and hand to every future conversation about this. Write it for a reader
  who has no memory of today — no "as we discussed."

Start by telling me the three things about this specific idea you'd need to
know that I haven't told you. Then ask me the first one.

I'm going to build something, and I don't want any code yet.

Your job in this conversation is to interrogate my thinking, not to design a
solution and not to agree with me. Ask one question at a time. Push back when
my answer is vague. If I give you a requirement that contradicts something I
said earlier, say so.

I'll answer as the domain expert. You are not the domain expert here — when
something depends on knowledge of my field, ask me rather than assuming.

Work through these, in order:

1. THE THING ITSELF
   - What am I actually building, in one sentence, with no adjectives?
   - What exists today, and why isn't it good enough?
   - What is explicitly NOT in scope? Make me name at least three things.

2. THE PEOPLE
   - Who touches this, and what were they doing five minutes before?
   - What are they actually trying to accomplish — not the feature they'd
     ask for, the outcome they want?
   - What do they already know? What will they never learn?
   - Who else is affected but never opens it?

3. WHAT "CORRECT" MEANS
   - How do I know an output is right? Be specific: exact match, a range, a
     judgment call, a human sign-off?
   - Where is "close enough" genuinely fine, and where is it not?
   - Who decides when we disagree about correctness?
   - What would a competent person in my field say if they saw this get it
     wrong?

4. HOW IT FAILS
   - Walk me through the ways this breaks. For each: how likely, how bad, and
     would we even notice?
   - Which failure is unacceptable — the one where I'd rather the whole thing
     refuse to run than produce that result?
   - What fails silently? That's the category I care about most.
   - What happens on the worst input someone could plausibly give it?

5. THE ONE RULE
   - Based on everything above, propose the single outcome this work must
     never violate. One sentence. I'll edit it.
   - Then: for each decision we've made, does it protect that rule or risk it?

6. DONE
   - What's the falsifiable test that proves this works? Not "it feels right."
   - What am I deliberately deferring, and where will I write that down so it
     isn't silently lost?

When we've been through all six, summarize back to me: the thing, the users,
the definition of correct, the failure modes ranked, the one rule, and the
acceptance test. Flag anything I was vague about. Then stop — still no code.