The question

What makes an unexpected rebuild, a close that never settles, or state that changes across restart a strong starting point for source research?

Working model

Observed friction already supplies a consequence and a boundary. Trace the anomaly back to the component that owns the result, then build a small native probe with a clean baseline failure. This is more informative than scanning for code that merely resembles a familiar defect.

Classify failures along the way. A product regression, invalid fixture, discovery bug, platform flake, and formatting failure do not ask for the same repair. The first incomplete step has an owner.

Exploration can be messy; the eventual review shape should be one minimal change, its native regression, and the governing invariant.

Provenance

Synthesized from the Vite correctness-lane process notes at Fieldwork revision 49e8c7dabbc75f021b09d243b1d95ecac215bb07.

Turn friction into a probe

Take one recent “that was weird” moment and write:

• the first observable mismatch;
• the smallest likely result owner;
• a baseline behavior that should fail;
• a control that proves the probe can distinguish the mechanism;
• a stop condition if the anomaly belongs to the fixture or environment instead.

Do not propose the patch yet.