Files

Mohamad Khani b9819977a5 logiguard fork v3: full patch set on verified 8c74db0 tree

Includes prior-session patches (carry forward so the app compiles):
  - crates/gpui/build.rs: cross-compile manifest fix
  - crates/gpui/src/platform.rs: PlatformWindow::activate_with_token trait method
  - crates/gpui/src/window.rs: Window::activate_with_token public API
  - crates/gpui_linux/src/linux/wayland/window.rs: WaylandWindow::activate_with_token + activate() keyboard-serial fix

Plus the focus-serial fix:
  - serial.rs: SerialKind::KeyboardEnter
  - client.rs: store wl_keyboard.enter serial; latest_serial_of()

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-14 01:52:12 +03:30

2.6 KiB

Raw Blame History

Crash Issue Linking

You are linking a crash to potentially related GitHub issues so human reviewers can quickly validate whether a fix may resolve multiple reports.

Inputs

Before starting, you should have:

Crash report (from script/sentry-fetch <issue-id> or Sentry MCP)
ANALYSIS.md from investigation phase, including root cause and crash site

If either is missing, stop and report what is missing.

Goal

Search GitHub issues and produce a reviewer-ready shortlist grouped by confidence:

High confidence
Medium confidence
Low confidence

The output is advisory only. Humans must confirm before adding closing keywords or making release claims.

Workflow

Step 1: Build Search Signals

Extract concrete signals from the crash + analysis:

Crash site function, file, and crate
Error message / panic text
Key stack frames (especially in-app)
Reproduction trigger phrasing (user actions)
Affected platform/version tags if available

Step 2: Search GitHub Issues

Search only issues in zed-industries/zed (prefer gh issue list / gh issue view / GraphQL if available) by:

Panic/error text
Function/file names
Crate/module names + symptom keywords
Similar reproduction patterns

Check both open and recently closed issues in zed-industries/zed.

Step 3: Score Confidence

Assign confidence based on evidence quality:

High: direct technical overlap (same crash site or same invariant violation with matching repro language)
Medium: partial overlap (same subsystem and symptom, but indirect stack/repro match)
Low: thematic similarity only (same area/keywords without solid technical match)

Avoid inflated confidence. If uncertain, downgrade.

Step 4: Produce Structured Output

Write LINKED_ISSUES.md using this exact structure:

# Potentially Related GitHub Issues

## High Confidence
- [#12345](https://github.com/zed-industries/zed/issues/12345) — <title>
  - Why: <1-2 sentence evidence-backed rationale>
  - Evidence: <stack frame / error text / repro alignment>

## Medium Confidence
- ...

## Low Confidence
- ...

## Reviewer Checklist
- [ ] Confirm High confidence issues should be referenced in PR body
- [ ] Confirm any issue should receive closing keywords (`Fixes #...`)
- [ ] Reject false positives before merge

If no credible matches are found, keep sections present and write - None found under each.

Rules

Do not fabricate issues or URLs.
Do not include issues from any repository other than zed-industries/zed.
Do not add closing keywords automatically.
Keep rationale short and evidence-based.
Favor precision over recall.

2.6 KiB Raw Blame History