context-discovery

Context Discovery

Gather only enough context for a confident execution decision or decision-complete durable plan. Ask only questions whose answers can change scope, architecture, risk, acceptance criteria, or user-visible behavior.

Question Budget

1. Start at the named working surface; inspect only the smallest code, test, or manifest evidence that resolves the question.
2. Ask one grouped question batch for the remaining material branches.
3. Use a second batch only if the first answer reveals a new costly or irreversible branch.
4. For reversible fast/standard decisions, proceed with an explicit reasonable assumption when clarification would cost more than correction.
5. Stop when another answer would not change the implementation, primary path, or assurance profile.

Do not ask for discoverable facts, preferences that do not affect the result, or exhaustive edge cases outside the requested scope.

UI Discovery

For production UI work, including small changes when the request names an existing/shared component, complete the ui-contract reuse gate before proposing components or visual rules. Inspect the closest screen, primitives, and visual source of truth; record receipt paths/exports, reuse/adapt/none, and structural verification in chat, plan, or handoff. Named reuse is architecture acceptance, not visual guidance.

Read Budget

These are hard gates. Count new file output; prefer slices over whole files.

• fast: diff or named surface; at most three files, two searches, and 12 KB.
• standard: at most four files, three searches, and 16 KB initially; eight files or 25 KB total unless the next read answers a named dependency.
• assurance or explicit audit: declare the extra surface before widening and keep each pass tied to a named risk.

No whole-repository scan without a named unknown. Stop when the direct path and tests are known. A new plan, compaction, retry, hand-off, or correction never resets these totals. At the cap, proceed, shrink, ask, or name the gap.