git:20260806.d473e0a to git:20260806.925accf

- The work file, the prompt, the glossary — all map. The codebase, its history, its real constraints — territory. The gap between them is the unknowns, and an unknown left unfound doesn't stay unfound: the diff review finds it, or production does.

-

- Sort any unknown into one of four kinds; the flow already mines three:

-

- | Kind | What it is | Who finds it |

- |---|---|---|

- | Known knowns | Already written down | The work file carries them |

- | Known unknowns | Questions you know are open | Wonder settles or parks them |

- | Unknown knowns | Obvious to the user, never said | The interview extracts them |

- | Unknown unknowns | On nobody's question list | **Only the territory can surface them — this skill** |

-

- An interview can't reach the fourth kind: it only asks questions someone thought to ask. This skill owns three moves for the moments the map is furthest from the territory. Each feeds a stage; none replaces one.

-

- ## Move 1 — the territory pass (before the work)

-

- When work enters an area the user names as unfamiliar, when interview answers keep coming back "I don't know", or when a whole discipline nobody on the work has judgment in walks in (a new subsystem, a new domain entirely) — walk the territory before anyone writes the brief.

-

- Read only — the code, its tests, its docs, and its history (log and blame of the area; reverted commits and bug-fix clusters are where it bit last time). Spawn the pass as a fresh subagent **on a frontier-tier model — the session's main model or better, never a cheaper one**. Hunting unknown unknowns is judgment, not reading: a cheap model reliably collects the potholes that are written down and then mis-calls the ones that aren't — measured twice (a greenfield pass that recommended the exact render path the project's fixed constraint forbade, corrected only by two later frontier stages; a 9/10-scored pass whose recommendations included quietly disabling a safety net). The report anchors every stage after it; this is the wrong place to save money. The subagent is still worth it for the fresh context — the main session consumes the report instead of re-walking the files.

-

- The pass explores unconstrained. It hunts findings no list predicted — so no taxonomy limits what it may notice; note whatever the territory shouts, then write the report. The report is still findings, never a tour of the files, organized into four fixed sections — the coverage floor, each covered or honestly reported empty — plus an open fifth that keeps the floor from becoming a ceiling:

-

- 1. **Questions you didn't know to ask** — decision points the territory forces that the ask never mentions. Each arrives as a question with your recommended answer, same discipline as the interview.

- 2. **What "good" looks like here** — the conventions, invariants, and quality bars this area already enforces; what a reviewer of this area would reject without discussion.

- 3. **Potholes** — where this area has bitten before, with the evidence: the reverted commit, the FIXME cluster, the test named after a bug. No history of bites? Say so — potholes are found, never manufactured.

- 4. **A sharper ask** — the user's request rewritten with the found unknowns settled or explicitly parked. Offer it back: "this is what I'd put in the brief."

- 5. **What fits no section** — the finding outside every bucket is often the load-bearing one: the subsystem already scheduled for replacement, the owner whose sign-off the work needs, the fact that changes whether the work should happen at all. Report it as itself, with its evidence — never shoehorned into the nearest section, never dropped for want of a home. Nothing found? Skip the section — it's a door, not a quota.

-

- Before offering any of it, collide your recommended answers with your own findings: a recommendation that quietly disables a safety net you just reported as a pothole, or divides money you just said must not be divided, is the pass contradicting itself — and it reads authoritative precisely because the rest of the report is right.

-

- Route the findings where they live: questions join the interview (`/wonder`), a term that wobbled goes to the `domain-glossary` skill, potholes become attack material for `/discern`, the sharper ask goes into the work file. Findings carry their evidence (the commit, the file, the test name) so consuming stages cite the report instead of re-exploring — a pass that gets re-verified file by file cost double and bought nothing. The pass writes no code and checks no gate — it exists so the stages that do have real material.

-

- ## Move 2 — teach before judging (at a choice)

-

- Watch for it whenever the user is confirming a choice — options from Invention, Discernment's recommendation, prototype directions. "Whichever you think", "they all look fine", an outright "I can't tell": that isn't agreement, it's a judgment gap. A confirmation from someone who can't evaluate the choice is an unknown wearing an approval, and it comes back later as "this isn't what I wanted."

-

- Name the dimensions along which the options actually differ. Teach just enough to hold an opinion — with material from *this* territory: a side-by-side, a before/after, the two lines that differ — not a lecture on the field. Then re-present the choice.

-

- If the user can judge now, their confirmation means something — record it. If they still can't, that is a delegated decision: record your pick as `assumed:` (the `genius-file` skill owns the idiom) instead of dressing it up as user-confirmed. An honest `assumed:` beats a hollow "sure, option A" — the returning reader knows to look at one; the other lies to them.

-

- ## Move 3 — quiz the map (before acceptance)

-

- Tenacity verifies the territory: tests run fresh, diff reviewed. Nothing verifies the user's *map* of it. Built work the user hasn't absorbed is next month's unknown knowns — decisions they now own and couldn't state.

-

- When built work is about to be accepted — Tenacity's close-out offers this, and delegated or auto work all but demands it, the user having watched none of the build — summarize what actually changed at the behavior level (from the diff and the work file: what happens differently now, what they will have to live with), then quiz. A few questions, one per message, each aimed at a consequence — "an upload fails twice; what happens on the third try?" — never trivia like filenames or line counts.

- A wrong answer is a finding about the map, not about the user: the explanation was thin or the change genuinely surprising. Repair the map — re-explain, or write the missing line into the work file or docs — then ask again. The quiz checks no gate; the work's evidence is Tenacity's job. Its finish line is the user answering clean — so they accept knowing what they accepted.

- ## What this skill is not

- - **Not the interview.** Wonder extracts what the user knows and never said; this skill surfaces what nobody knew. A territory-pass finding that needs a user decision becomes an interview question — Wonder's, not this skill's.

- - **Not review.** Tenacity's reviewer judges the work against the brief; the quiz judges the user's map against the work. Either can fail while the other passes.

- - **Not divergence.** Invention owns generating options; Move 2 only teaches how to choose among options that already exist.

- - **Not a stage.** It has no gate and never sets `stage:`. It feeds the gates the stages own.