# After the Walk

The map lives on past planning. Three moves for the phases that follow.

- **Implementation notes** (during the build) — keep a running log; every
  time the code forces a deviation from the plan, record what the plan said,
  what the code revealed, and the conservative call made, then keep going.
  Tag entries that need the user's judgment. Each deviation is an unknown
  unknown that escaped the walk — fold it back into the map for attempt #2.
- **The buy-in doc** (before shipping) — other people inherit your unknowns;
  package prototype, spec, and notes into one skimmable pitch that leads with
  a demo, pre-answers each reviewer's objections with evidence, and names who
  signs off on what.
- **Quiz before merge** (before merging someone else's or a long diff) — a
  merge-readiness report — mental model, non-obvious behaviors introduced,
  what to watch after deploy — ending in a quiz the user must pass; wrong
  answers point back to the section they skimmed.

# Stage 1 — Known Knowns: Open with the Settled Ground

Your first reply shows the map as it stands: what is already settled, so the
rest of the walk only spends the user's attention on what isn't.

## Scan first (silent)

Before saying anything about the code, walk the territory. Use subagents in
parallel — split the code the task touches among them and collect what they
pin down — so the opening lands fast instead of after a long serial read.
Gather: what already exists for this task (including half-built or reverted
prior attempts), the data shapes and conventions the code enforces, and
anything that smells load-bearing for the request.

## The opening reply

- List the settled ground: the request as you understand it, the facts the
  territory pins down (cite files), constraints and decisions already made.
  Distinguish what is locked from what you are merely assuming — flag
  assumptions as "settled unless you say otherwise."
- Name the three quadrants you will walk next, one line each, so the user
  sees the shape of the conversation.
- If the scan already surfaced a load-bearing finding — a landmine that
  changes what the task even is — disclose it in this opening and file it
  under its quadrant. Do not save it for its stage.
- The first stage-2 question may ride along in this same message; nothing
  else jumps ahead.

**Done when** the user has the settled ground with citations, knows which
assumptions you are treating as settled, and can see the three stages ahead.

# Stage 2 — Known Unknowns: The Questions You Can Name

The questions that must be answered but aren't yet. You know the question;
the answer lives with the user or in the territory.

## Procedure

1. Inventory the questions the task cannot proceed without, and disclose the
   queue ("still queued after this: …") so the user sees how much walk
   remains.
2. Before asking another question, apply the main skill's preference
   checkpoint when due. Otherwise resolve them **one at a time, highest
   architectural blast radius first** — never a wall of questions. Give your
   recommended answer with each, as lettered options the user can answer in
   a few characters, so they react
   rather than compose.
3. Close every question one of four ways:
   - **Answered by the user.**
   - **Answered by the agent on the user's behalf** — only under the
     preference checkpoint's opt-in and disclosure rules.
   - **Answered by the territory** — go read it instead of asking, then show
     the user the question and the found answer. A question closed off-screen
     isn't closed.
   - **Recorded as OPEN on the map** — explicitly deferred, with what
     unblocks it.

**Done when** every named question is closed one of those ways, in front of
the user. Announce the stage closed (a small decisions table recaps it well)
before crossing into stage 3.

## Techniques

- **The interview** — the stage's default mechanic: one question per turn,
  ordered by blast radius, each with a recommendation; end with a decisions
  table.
- **Brainstorm the intervention** — when the question is "which solution?":
  search the codebase first, then plot ~10 interventions from
  ship-this-afternoon to quarter-long bet, each grounded in what actually
  exists (half-built features behind flags and disconnected wiring are the
  cheapest wins); resonate-checkboxes assemble the reply.
- **Point at a reference** — when an existing implementation encodes the
  wanted behavior: produce a semantics map proving you understood it — what
  it does with excerpts, how each behavior maps to the target stack, every
  place the port cannot be literal. Nothing gets ported until sign-off.

# Stage 3 — Unknown Knowns: Extract What Was Never Articulated

The user (or the codebase) holds answers nobody has put into words: taste,
vocabulary, tacit conventions, context that would otherwise surface as "oh —
one thing I forgot to mention" after it's too late. You cannot ask for these
directly; asking "what do you want?" gets a shrug.

## Procedure

1. Hand over something concrete to react to (see techniques below). Ground it
   in the user's real data so the thing being judged is the only variable.
2. Probe for unstated context the user wouldn't think to volunteer: **who
   consumes this, where does it run, what does done look like to whoever
   inherits it.** Ask these deliberately — the decisive constraint usually
   arrives as a throwaway remark, and this probe is how you stop depending on
   luck.
3. When an extracted fact reshapes earlier decisions, say so and update the
   map — quadrants are a living record, not a script.

**Done when** the user has reacted to something concrete, the context probes
are answered (or explicitly shrugged off), and the extracted answers are on
the map.

## Techniques

- **Design directions** — render the same real data four incompatible ways so
  the only variable is the design; steal/skip chips under each assemble the
  reply. For users who will know it when they see it.
- **Mock before you wire** — a throwaway clickable mock with fake data —
  toggleable placements, A/B questions — before touching the real app; the
  user finds out what they want the moment they can click it.
- **Teach the vocabulary** — when the request is vague because the user lacks
  the domain's words, ladder from their words to the professional terms, each
  rung paired with the precise prompt it unlocks.
- **The concrete sample** — for non-visual outputs (a file format, an API
  response, a report), show the actual artifact with labeled fake data and
  per-line steal/skip choices, instead of asking the user to imagine columns.

# Stage 4 — Unknown Unknowns: Hunt the Landmines

What neither of you knows to ask, the territory often does. This stage sweeps
the code the task will touch and turns silent traps into map entries.

## Procedure

1. Sweep every file the task touches (state the coverage: "the sweep covered
   the N files this task touches"). Hunt for:
   - **Landmines** — things that bite silently: wrong-by-default data,
     stale denormalizations, filters that pass bad rows, escaping that
     corrupts output.
   - **Unwritten conventions** — rules the code enforces that no doc states.
   - **Half-built or reverted prior attempts** at the same job, and *why*
     they died — the reason is usually your landmine.
   - **Findings beyond the feature** — latent bugs the task's code path
     inherits; escalate them to the map rather than silently absorbing them.
2. Report each finding as a card: the **evidence** (file and line), **why it
   bites**, and **what it changes** about the task. Worst first.
3. A finding that needs a decision follows the stage-2 closure rules,
   including preference-based delegation when applicable. If asking the user,
   give lettered options with your recommendation. A finding that only needs
   awareness goes straight on the map as a sharp edge.

Remember the global rule: findings that bear on decisions already in flight
should have been disclosed when found — this stage is where the *systematic*
sweep happens, not where disclosures wait.

**Done when** the sweep has covered the code the task will touch and every
finding is on the map — decided, OPEN, or noted as a sharp edge.

## Technique

- **Blindspot pass** — the sweep packaged for reaction: landmine cards, each
  with the evidence, why it bites, and a copyable prompt fix; assembled into
  one better implementation prompt at the end.

# Stage 5 — Hand Over the Map

The walk's deliverable. Close by assembling the completed four-quadrant map
as one artifact the user keeps.

## The map artifact

One self-contained page holding all four quadrants:

- **Known knowns** — the settled ground, with file citations.
- **Known unknowns** — the decision ledger: every named question with its
  answer and who closed it (user / territory / agent on the user's behalf /
  OPEN). Agent answers retain the preference and reason behind each choice,
  alongside the confirmed preference summary and delegation scope. OPEN
  items state what unblocks them.
- **Unknown knowns** — what got extracted: taste, consumers, environment,
  tacit conventions, and what each reshaped.
- **Unknown unknowns** — the landmine cards with evidence, each marked
  decided, OPEN, or sharp-edge.

Anything still open lives on the map, not in scrollback. Small facts the
builder must confirm before coding get their own list — they are map
entries, not footnotes.

## What rides along

- **A build plan may accompany the map — never replace it.** Sort it as a
  **tweakable plan**: by likelihood-of-tweaking, not execution order —
  judgment calls first with their alternatives toggleable, mechanical work
  collapsed at the bottom ("I trust you on that part").
- **A copyable implementation prompt** — the user's next message pre-drafted,
  so kicking off the build is a paste.

**Done when** the user holds the map. Implementation is a separate task that
starts from it — offer to begin, and point at
[after the walk](after-the-walk.md) for how the map lives on during the
build.