validate-issue

# validate-issue Validate a GitHub issue by tracing every factual claim to the code — never trust the author's description of current behavior, even the repo owner's. Validate **everything** the issue asserts, not just "Current Behavior": a named root cause, cited `file:line`, or recommended fix are *additional* claims, not shortcuts — a confident root cause can point at the wrong path, a citation can be stale, a fix can be infeasible even when the symptom is real, so run the proposal through 5a/5c however authoritative it reads. The deliverable is one end-to-end judgment — summary, behavior, root cause, citations, fix. ## Input The user provides one of: - Full URL: `https://github.com/<owner>/<repo>/issues/<N>` - Short form: `#<N>` or just `<N>` (use the current repo) - `owner/repo#N` - **Nothing** — default to the latest (most recently created) open issue in the current repo. ## Steps ### 0. Baseline: validate against the current default branch — NO worktree yet **Do not create a worktree for validation or for `update issue` edits.** A worktree is created only when the user explicitly says to **work on** the issue (step 7.5) — validation and title/description edits run from the existing checkout. So that claims trace against the repo's current default branch (`main`, `master`, or whatever the repo uses — never assume) rather than a stale or divergent local checkout, resolve it and refresh the baseline first: ```bash DEFAULT=$(gh repo view --json defaultBranchRef --j...