dig: cross-domain root-cause digging

Iron rule: no fix before the root cause is found. Making the symptom disappear and solving the problem are two different things. This rule applies to every kind of anomaly: code, data, metrics, process.

Repeated failure is the entry signal: a fix that did not fix ("改了还是不行", still failing after changes) means the guessing phase is over. Stop patching from memory and start here. The cause-known boundary runs the other way: when the cause is already understood, skip this skill and take the fix straight through coding's red path. Diagnosis, source fix and regression all complete inside this skill, no forced handoff.

Diagnosis is a thinking activity, and each step is driven by a thinking engine: what an engine gives you isn't terminology, it's the question that step should ask.

The deliverable of a non-trivial dig is .issues/<YYYY-MM-DD-topic>/issue.md: the symptom and reproduction, the hypothesis list with a verdict on each, the probe log, the root-cause reconciliation, the fix, and the regression line. Create it when the dig starts, append as verdicts land. When the user wants it published, rewrite it from the confirmed understanding into issue or PR text, never by copying the working file. Before writing to disk, make sure the draft directory is ignored: if git check-ignore .issues fails, append .issues/ to .git/info/exclude (a local ignore, leaving the shared .gitignore untouched) and let the user know. In a non-git environment there's no commit risk, so write directly. This file is three things at once: the vehicle for showing the user the hypothesis list, the counter for the three-strikes stop-loss, and the working memory for picking the investigation back up if the session gets interrupted. Small, obvious problems can skip it, but a dig entered through repeated failure never does: this file is the three-strikes counter, and a problem that already survived two fixes is not small.

1. Reproduce and pin down the symptom

Turn the anomaly into something you can observe with certainty: for a code problem, build a minimal, repeatable reproduction. For a data problem, take the raw data and compute it yourself. For a metric problem, pin down the exact definition and time window. If you can't reproduce it, keep gathering observations, don't start fixing. A flaky symptom is a reproduction-rate problem: loop the trigger, parallelise, add stress, narrow the timing window until the rate is high enough to debug against. A 50% flake is debuggable, a 1% one is not, so raise the rate first.

What counts as "fixing": only a change that alters behavior counts. Read-only probes, diagnostic scripts, and pure scaffolding added for testability (exporting a function, wrapping a main guard, as long as you verify zero behavior change) don't count, and don't need to clear the hypothesis gate.

2. Generate hypotheses: the first-principles engine

Don't ask "what similar bug have I seen before" (pattern matching is fertile ground for anchoring). Ask instead: "For this symptom to be true, what facts have to hold?" Break the symptom into a chain of necessary conditions. Every link in that chain is a suspect, and every suspect generates a hypothesis.