Runtime Evidence-Driven Debugging

Role: The methodology layer for runtime debugging — answers when to escalate from static analysis to runtime observation, and how to gather, analyze, and act on runtime evidence. Referenced by PDCA hosts via frontmatter dependencies (invoked after a prerequisite check). It delegates tool selection to browser-debug-toolkit and domain analysis to hybrid-debug.

Detailed framework entries (author, year, method, source) and instrumentation templates live in reference.md.

Why this skill exists

Static code analysis — reading code, tracing call chains, reasoning about logic — has a ceiling. It cannot observe:

• Runtime data flow: what value a variable actually holds at execution time
• Call ordering: which function runs first when timing matters
• Platform/host interception: silent behavior changes imposed by WebView, Electron, OS-level controls, or framework runtime — invisible in source code

When root-cause confidence is "fuzzy" or "unknown" after static analysis, the disciplined response is not to re-read the same code harder. It is to escalate to runtime evidence gathering — add targeted instrumentation, reproduce the problem, observe the actual execution, and anchor the root cause in observed fact rather than inferred logic.

This skill provides that methodology. The meta-lesson:

A root cause confirmed by runtime observation is an order of magnitude more trustworthy than one inferred from reading code. When confidence is low, do not reason harder — gather evidence.