Exclude current issue from triage related-issue search

[dcellison]

Summary

Exclude the current issue from its own related-issue search results in the triage pipeline. Previously, search_related_issues() could return the issue being triaged as one of its own related issues, causing Claude to flag it as a duplicate of itself.

Changes

Change	Detail
issue_number parameter	Added to search_related_issues() (default 0 for backward compat)
Result filtering	Parsed JSON filtered to remove matching issue number
JSON validation	Raw gh output now parsed and re-serialized; invalid JSON returns "[]"
Caller update	triage_issue() passes metadata.number

Test plan

• test_excludes_current_issue - issue Remove redundant foreign workspace memory injection #42 removed, others preserved
• test_empty_after_exclusion - sole result is current issue, returns empty
• test_invalid_json_returns_empty - garbage from gh returns "[]"
• Existing tests pass (no issue_number uses default 0, no filtering)
• All 1135 tests pass, make check clean

Fixes #164

[dcellison]

Review by Kai

This is a clean, focused fix. One minor finding and a couple of suggestions:

---

SUGGESTION — triage.py:194-198: Non-list JSON silently falls to outer handler

If gh ever returns a valid but non-array JSON value (e.g. an error object {}), json.loads succeeds, but the list comprehension [i for i in issues if i.get("number") != ...] will call .get() on string keys and raise AttributeError. This propagates past the json.JSONDecodeError handler and gets swallowed by the outer except Exception, logging "Failed to search related issues" — a misleading message for what's actually a malformed-but-valid JSON response.

This isn't a regression (the pre-existing code had no protection here either), but since you're already adding JSON parsing, a isinstance(issues, list) guard would close it cleanly:

issues = json.loads(raw)
if not isinstance(issues, list):
    return "[]"

---

SUGGESTION — triage.py:195: Truthiness check as sentinel

if issue_number: works correctly since GitHub issue numbers are 1-indexed, making 0 a safe "not provided" sentinel. Worth a brief comment to make the intent explicit, since a reader might wonder if issue_number=0 is an accidental falsy edge case.

---

No bugs, no security issues. The issue_number: int = 0 default preserves backward compatibility, the filter logic is correct, JSON re-serialization is safe, and all three new tests cover the meaningful cases. The behavioral change (raw gh output now always goes through json.dumps even when no filtering occurs) is fine — callers parse it as JSON anyway.

[dcellison]

Review by Kai

Both suggestions from the prior review were addressed: the isinstance(issues, list) guard is present, and the sentinel comment is in place. No new issues.

Clean. The implementation is correct and the three new tests cover the meaningful cases. One minor observation that doesn't warrant blocking:

SUGGESTION — triage.py:198: Non-dict items in a valid list

If gh ever returns a valid JSON array with non-dict elements (e.g. [1, 2]), i.get("number") would raise AttributeError, falling through to the outer except Exception and logging "Failed to search related issues." Practically impossible for gh issue list output, and not a regression — just noting it since the list-type guard added above is in the same spirit. A guard like isinstance(i, dict) in the comprehension would be fully defensive, but this is firmly in the "not worth it" category for real-world gh output.

Everything else looks good: backward compatibility is preserved, JSON re-serialization is safe, the caller correctly passes metadata.number, and the test coverage is solid.