Find how this codebase gets into a live process, and use that. Not a bare interpreter, and not a mock.

• Python: python with the package importable, or ipython. Check for a conftest.py, a shell.py, or a management command that sets up context.
• Ruby: rails console, or irb -r ./lib/<project>.
• Elixir: iex -S mix. Clojure: lein repl or clj in the project.
• Node: node --require ./index.js, or npx tsx for TypeScript.
• Haskell: cabal repl. Scala: sbt console.

Where the runtime cannot load and redefine code, the test runner is the REPL. Go, Rust, C#, Java, C++. Write a scratch test, run it, edit, re-run. go test -run TestScratch, cargo test scratch, dotnet test --filter. The test harness reaches internals a scratch binary cannot: in-package Go tests see unexported identifiers, Rust #[cfg(test)] sees private items, .NET test projects reach internal.

Do not install a REPL. If the toolchain did not ship one and the project does not use one, that absence tells you which mode you are in. Something marketed as a REPL that recompiles per snippet gives none of the benefit and costs an install.

Call the real functions with real data shapes. The point is to find out what the system does, not to confirm what you think it does.

• Start from the entry point the ticket names and follow it down.
• Use realistic inputs, including the size and shape that the ticket says is failing.
• Measure when the question is about cost: time it, trace memory, count queries.
• Push it until it breaks, and note where.
• When the behavior depends on state, set the state up and vary it.

Reading source and reasoning about it is not this. Source tells you what was intended. Running tells you what happens. When the two disagree, the run is right, and that disagreement is usually the most valuable thing you will find.

Before each probe, state what result would prove you wrong. One line. A probe that cannot fail proves nothing and will happily flatter whatever you already believed.

Then run it, and write down what actually came back, including the numbers.

Each answer raises the next question. That is the loop working. Stop when a round produces no new questions, or after about three rounds.

A question that names a symbol, a file, a version, an API, or a config key is factual. Resolve it yourself by reading or by running. Do not hand it to the user.

Only judgment questions reach the user: preference, priority, risk appetite, scope. Each one must state why neither reading nor running settles it.

A well-worded question reads like progress, which is the trap. Check its shape, not how it feels.

Scripts live in repl/ inside the planning directory, committed. They are the answer to "why did we decide this" six months later.

Keep the output too when the finding is visual. A render, a chart, a screenshot of the broken state. The script says what was measured; only the artifact shows what it looked like, and nobody re-runs a script to settle an argument. Keep them small and keep the ones that carry the finding, not every intermediate.

Commit as you go. Never push.

Commit the planning directory whenever a probe answers something: the script, the output that carries the finding, and the paragraph it produced. Not at the end of the session. A REPL session is hours of work that exists only on disk until someone commits it, and losing it means losing the reasoning behind every decision that followed.

Pushing is a separate act with a separate audience, and it is the user's to make. Commit, say what you committed, and leave it there.

Findings go in the documents. A finding that informs a claim gets cited inline with its numbers. A finding that informs a test earns a row in the CUJ document's Informed by column later.

A scratch test is not a test. It stays in repl/ and never joins the suite.

This is what "high level" means, concretely. Apply both questions to your own draft. Both answers must come out right.

• Could two competent engineers read this and implement it differently, and both be right? Must be yes. A no means you have made implementation decisions that belong in the CUJ document, and the pipeline has collapsed into one document with a fold in the middle.
• Could two competent engineers read this and disagree about whether the ticket was satisfied? Must be no. A yes means you have not said what better looks like.

Both take one read to answer. Run them before showing the document to anyone, and again after any round of edits, because the usual drift is downward into detail.

Length is a symptom of the same thing. A document running well past two pages has usually started making decisions the next document should be making. The two questions are the rule; the page count is just the cheap early warning.

Expect to revise it while the user argues with it. Keep researching during that argument rather than waiting; most objections are answerable by running something.